On 17.11.25 13:51, Jan Beulich wrote:
On 17.11.2025 13:37, Jürgen Groß wrote: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-generatedNo. 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.As Andrew indicated, Paths.mk might have changed, so at the very least an explicit dependency would need adding. But as alluded to elsewhere, I'm not
Yes, and I said that already.
quite convinced Paths.mk should be hard-coded as the sole source of patterns in Config.mk. At the point further such file come into play, dealing with the dependencies might get interesting / clumsy.
See my answer to your next reply.
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 ...For some of the cases this might actually be worthwhile. It all depends on how much of a knock-on effect the re-building of a particular file has.
As long as the effect is not WRONG (which isn't the case with my patch series), I think we have to consider how often this would be the case. Optimizing the build time for one case in 10.000 builds (and I think the ratio in the case of my series is even more extreme) while making the build time even only a tiny bit longer for all the other cases is a bad idea IMHO. And the build time will be slower with using a tmp file and invoking the move-if-changed macro. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
