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
