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

[Jürgen Groß <jgross@xxxxxxxx>]

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: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature