Re: [PATCH v2 1/4] build: add make macro for making file from file.in

[Jan Beulich <jbeulich@xxxxxxxx>]

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

Jan