Re: [PATCH v2 2/4] docs: replace @xxx@ markers at build time

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.11.2025 13:55, Jürgen Groß wrote:
> On 17.11.25 13:33, Jan Beulich wrote:
>> On 14.11.2025 14:00, Jürgen Groß wrote:
>>> On 14.11.25 12:40, Andrew Cooper wrote:
>>>> On 14/11/2025 11:32 am, Juergen Gross wrote:
>>>>> diff --git a/docs/Makefile b/docs/Makefile
>>>>> index 37776d303c..e5f4a8ca86 100644
>>>>> --- a/docs/Makefile
>>>>> +++ b/docs/Makefile
>>>>> @@ -8,8 +8,11 @@ DATE             := $(call date,"+%Y-%m-%d")
>>>>>    DOC_ARCHES      := arm ppc riscv x86_32 x86_64
>>>>>    MAN_SECTIONS    := 1 5 7 8
>>>>>    
>>>>> +IN_FILES := man/xl-disk-configuration.5.pod 
>>>>> man/xl-network-configuration.5.pod
>>>>> +IN_FILES += man/xl.1.pod man/xl.cfg.5.pod man/xl.conf.5.pod
>>>>
>>>> Sorry, I meant to say this on the previous revision.  Can we please list
>>>> these one per line, for the future ease of inserting/removing.
>>>
>>> Okay.
>>>
>>>> Is IN_FILES really correct?  These are the generated (non-.in) files,
>>>> rather than the .in files themselves.  GEN_FILES from v1 would seem to
>>>> be a better fit.
>>>
>>> I wanted to make clear this is related to *.in files. And IMHO GEN_FILES
>>> was too generic on a second thought.
>>>
>>> GENERATED_FROM_IN_SUFFIXED_FILES seems a little bit clumsy. ;-)
>>> Seriously, if you have any better name, I'd be happy to use it.
>>
>> GEN_POD_FILES, seeing they're all *.pod?
> 
> For this case, maybe. OTOH in case someone adds a .podman file we'd need
> to rename again.
> 
> And I think using the same make variable name in all Makefiles needing to
> specify *.in derived files would be preferable.
> 
> Maybe IN_TARGETS?

Better than IN_FILES, but still potentially ambiguous. How about sticking
to IN_FILES but indeed enumerating the .in there (zapping the suffix upon
use)? And/or would $(wildcard <path>/*.in) perhaps make sense to use?

Jan