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') <$$< >$$@ +endefShouldn'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
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
