On 17.11.2025 14:10, Jürgen Groß wrote:
> 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).
Sticking to Paths.mk (which sits in the global config/ subtree anyway) might
be okay. The new (tools/ specific aiui) file you add later doesn't really
belong there, though. Therefore the macro may want to be constructed such
that it can be used both ways.
Jan
