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

["Jürgen Groß" <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2493 bytes --]

On 17.11.25 14:00, Jan Beulich wrote:
> 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?

Zapping the suffix upon use would be possible, but more clumsy (there are
normally at least 3 direct uses of IN_FILES in each affected Makefile, while
there are 0 use cases of the .in suffixed source files).

Using a local make variable for speeding that up would have the same problem
as before: how to name it?

And using $(wildcard <path>/*.in) is not an option, as that would reintroduce
the need to distinguish the configure-time and build-time *.in files, which
I solved in V1 of my series by renaming the build-time ones to *.src.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]