Re: [PATCH v2 1/4] build: add make macro for making file from file.in

[Jürgen Groß]

On 17.11.25 13:30, Andrew Cooper wrote:

On 17/11/2025 12:24 pm, Jan Beulich wrote:

On 14.11.2025 13:54, Jürgen Groß wrote:

On 14.11.25 12:42, Andrew Cooper wrote:

On 14/11/2025 11:32 am, Juergen Gross wrote:

diff --git a/Config.mk b/Config.mk
index e1556dfbfa..d21d67945a 100644
--- a/Config.mk
+++ b/Config.mk
@@ -159,6 +159,19 @@ define move-if-changed
        if ! cmp -s $(1) $(2); then mv -f $(1) $(2); else rm -f $(1); fi
   endef

+INC_FILES := $(foreach f, $(PATH_FILES), $(XEN_ROOT)/config/$(f).mk)
+
+include $(INC_FILES)
+
+BUILD_MAKE_VARS := $(foreach f, $(PATH_FILES), $(shell awk '$$2 == ":=" { 
print $$1; }' $(XEN_ROOT)/config/$(f).mk.in))
+
+# Replace @xxx@ markers in $(1).in with $(xxx) variable contents, write to $(1)
+define apply-build-vars
+ $(1): $(1).in
+       sed $$(foreach v, $$(BUILD_MAKE_VARS), -e 's#@$$(v)@#$$($$(v))#g') <$$< 
>$$@
+endef

+PATH_FILES := Paths

Shouldn't this write to a tmp file, and use move-if-changed?  Most of
the time the markers won't have changed, and we'll want to short circuit
dependent rules.

I can see this being an advantage when e.g. generating header files, as
those being generated again would potentially cause lots of rebuilds.

In this case I can hardly see any case where make wouldn't do the right
thing already. Either the *.in file is newer than the generated file due
to a git update or a manual edit, so make will regenerate the target (and
this is what we want), or the *.in file hasn't changed, so make won't
regenerate the file as it is newer than the *.in file already.

Or did I miss some aspect?

Aren't some of the generated files Makefile fragments? Them being re-generated
means make re-invoking itself, which could be avoided if the contents don't
really change. (This isn't just a performance concern; this re-invocation has
been the source of, well, surprising behavior in certain cases.)

Having thought about this some more, it needs to be FORCE and
move-if-changed, or to express a dependency on Paths.mk

I said that already in the paragraph just after the part of my response you
cited.


Juergen

OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature