On 17.11.25 13:54, Jan Beulich wrote:
On 17.11.2025 13:48, Jürgen Groß wrote:On 17.11.25 13:29, Jan Beulich wrote:On 14.11.2025 12:32, Juergen Gross wrote:--- 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)Is any of the above part of introducing the macro? "Paths" is already a specific case of holding patterns that want replacing. In turn ...+BUILD_MAKE_VARS := $(foreach f, $(PATH_FILES), $(shell awk '$$2 == ":=" { print $$1; }' $(XEN_ROOT)/config/$(f).mk.in))... it's not quite clear to me how it can be $(PATH_FILES) here.See patch 4. PATH_FILES is specifying the .mk files containing the marker definitions. I need the ability to have multiple such files in order to be able to let tools/configure build its own definitions.That's a good example - why would that affect the stubdom/ part of the tree? Imo what pattern file(s) to use wants leaving to the invokee of the macro, not pinning down globally for everyone.
Yes, I could add the tools specific marker file in the use cases under tools. The question is whether adding it to 6 Makefiles is really worth that optimization, especially as only building the man files would be effected right now (which could change in future, of course). Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
