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

[Jan Beulich <jbeulich@xxxxxxxx>]

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') <$$< 
>>>>> >$$@
>>>>> +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
> 
> 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.

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

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

Jan