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

[Jürgen Groß]

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.1.pod man/xl.cfg.5.pod man/xl.conf.5.pod

+IN_FILES := man/xl-disk-configuration.5.pod man/xl-network-configuration.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

OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature