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

["Jürgen Groß" <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 4157 bytes --]

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

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]