On 17.11.25 13:24, 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
+PATH_FILES := Paths
+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

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

No.

Man-pages, shell scripts and some Ocaml files (one config file and one .ml file,
which is similar to an include file I believe).

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.)

I still don't see a case where make would consider rebuilding the file from
its .in file without the .in file having changed, thus resulting in the built
file to change, too. Well, with one probably very rare exception: in case a
different @marker@ is used in the .in file, but without changing the resulting
file due to old and new marker resulting in the same output.

In case we really care about such cases, we should think about using
move-if-changed everywhere, as e.g. building a program with $HOSTCC could
result in an unchanged binary even with source files having changed, and the
resulting program could be used to generate other files ...


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to