Use the apply-build-vars make macro to replace the @xxx@ markers in
*.in files only at build time.
This allows to change the affected document files without having to
run "configure" for making the change effective.
While at it add the generated files to the distclean make target.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
V2:
- don't rename source files
---
docs/Makefile | 8 +++++++-
docs/configure | 7 +------
docs/configure.ac | 9 +--------
3 files changed, 9 insertions(+), 15 deletions(-)
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
+
# Documentation sources to build
-MAN-SRC-y := $(sort $(basename $(wildcard man/*.pod man/*.pandoc)))
+MAN-SRC-y := $(sort $(basename $(wildcard man/*.pod man/*.pandoc) $(IN_FILES)))
RST-SRC-y := $(sort $(filter-out %index.rst,$(shell find * -type f -name '*.rst' -print)))
@@ -77,11 +80,14 @@ clean: clean-man-pages
distclean: clean
rm -rf $(XEN_ROOT)/config/Docs.mk config.log config.status config.cache \
autom4te.cache
+ rm -f $(IN_FILES)
# Top level install targets
.PHONY: man-pages install-man-pages clean-man-pages uninstall-man-pages
+$(foreach file,$(IN_FILES),$(eval $(call apply-build-vars,$(file))))
+
# Metarules for generating manpages. Run with $(1) substitued for section
define GENERATE_MANPAGE_RULES
diff --git a/docs/configure b/docs/configure
index 98dda3cd0f..8871914dcb 100755
--- a/docs/configure
+++ b/docs/configure
@@ -1794,7 +1794,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
-ac_config_files="$ac_config_files ../config/Docs.mk man/xl.cfg.5.pod man/xl.1.pod man/xl-disk-configuration.5.pod man/xl-network-configuration.5.pod man/xl.conf.5.pod"
+ac_config_files="$ac_config_files ../config/Docs.mk"
@@ -3063,11 +3063,6 @@ for ac_config_target in $ac_config_targets
do
case $ac_config_target in
"../config/Docs.mk") CONFIG_FILES="$CONFIG_FILES ../config/Docs.mk" ;;
- "man/xl.cfg.5.pod") CONFIG_FILES="$CONFIG_FILES man/xl.cfg.5.pod" ;;
- "man/xl.1.pod") CONFIG_FILES="$CONFIG_FILES man/xl.1.pod" ;;
- "man/xl-disk-configuration.5.pod") CONFIG_FILES="$CONFIG_FILES man/xl-disk-configuration.5.pod" ;;
- "man/xl-network-configuration.5.pod") CONFIG_FILES="$CONFIG_FILES man/xl-network-configuration.5.pod" ;;
- "man/xl.conf.5.pod") CONFIG_FILES="$CONFIG_FILES man/xl.conf.5.pod" ;;
*) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
esac
diff --git a/docs/configure.ac b/docs/configure.ac
index c2e5edd3b3..43dc516056 100644
--- a/docs/configure.ac
+++ b/docs/configure.ac
@@ -5,14 +5,7 @@ AC_PREREQ([2.67])
AC_INIT([Xen Hypervisor Documentation], m4_esyscmd([../version.sh ../xen/Makefile]),
[xen-devel@lists.xen.org], [xen], [https://www.xen.org/])
AC_CONFIG_SRCDIR([misc/xen-command-line.pandoc])
-AC_CONFIG_FILES([
-../config/Docs.mk
-man/xl.cfg.5.pod
-man/xl.1.pod
-man/xl-disk-configuration.5.pod
-man/xl-network-configuration.5.pod
-man/xl.conf.5.pod
-])
+AC_CONFIG_FILES([../config/Docs.mk])
AC_CONFIG_AUX_DIR([../])
# M4 Macro includes
--
2.51.0On 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. 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. But, overall I think this is a nicer change. > + > # Documentation sources to build > -MAN-SRC-y := $(sort $(basename $(wildcard man/*.pod man/*.pandoc))) > +MAN-SRC-y := $(sort $(basename $(wildcard man/*.pod man/*.pandoc) $(IN_FILES))) Doesn't the man/*.pod wildcard do this already ? ~Andrew
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. > But, overall I think this is a nicer change. > >> + >> # Documentation sources to build >> -MAN-SRC-y := $(sort $(basename $(wildcard man/*.pod man/*.pandoc))) >> +MAN-SRC-y := $(sort $(basename $(wildcard man/*.pod man/*.pandoc) $(IN_FILES))) > > Doesn't the man/*.pod wildcard do this already ? Not if only the man/*.pod.in file is there, so the man/*.pod file needs to be made first. Juergen
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? Jan
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? Juergen
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
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
On 17.11.2025 14:17, Jürgen Groß wrote: > 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, Hmm, yes, if there's a mix of them in any one directory, that wouldn't work. Jan > which > I solved in V1 of my series by renaming the build-time ones to *.src. > > > Juergen
© 2016 - 2025 Red Hat, Inc.