Re: [PATCH RFC] build: detect outdated configure outputs

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.03.2021 12:46, Roger Pau Monne wrote:
> The Xen build system relies on configure to parse some .in files in
> order to do substitutions based on the data gathered from configure.
> 
> The main issue with those substitutions done at the configure level is
> that make is not able to detect when they go out of date because the
> .in file has been modified, and hence it's possible to end up in a
> situation where .in files have been modified but the build is using
> outdated ones. This is made even worse because the 'clean' targets
> don't remove the output of the .in parsing, so doing a typical `make
> clean && make` will still use the old files without complaining.
> Note that 'clean' not removing the output of the .in transformations
> is the right behavior, otherwise Xen would require re-executing the
> configure script after each clean.
> 
> Attempt to improve the situation by adding a global rule that spot the
> outdated files as long as they are properly listed as makefile target
> prerequisites.
> 
> Ultimately those substitutions should be part of the build phase, not
> the configure one.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> RFC because I'm not sure if there's some better way to handle this.
> Also I think we would want to make sure all the .in outputs are
> properly listed as target prerequisites, or else this won't work.
> 
> Also not sure whether this will break some other usage of .in files
> I'm not aware.

There are a number of such files in the tree which aren't used to
record configure results. Whether their existence could actually
case a problem with this approach I can't tell. Would it be
possible to ...

> --- a/Config.mk
> +++ b/Config.mk
> @@ -65,6 +65,10 @@ DEPS_RM = $(DEPS) $(DEPS_INCLUDE)
>  %.d2: %.d
>       sed "s!\(^\| \)$$PWD/! !" $^ >$@.tmp && mv -f $@.tmp $@
>  
> +# Make sure the configure generated files are up to date
> +%: %.in
> +     $(error $@ is outdated, please re-run configure)

... make this a static pattern rule for just the file names that
are actually processed / produced by configure? Of course it
wouldn't be very nice to have to keep in sync that list and what
the various configure.ac scripts list in AC_CONFIG_FILES() et al.
But not listing the targets explicitly would always risk the rule
to kick in for a file where it's not supposed to apply.

Jan