Re: [PATCH] build/xen: fail to rebuild if Kconfig fails

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.02.2024 13:11, Jan Beulich wrote:
> On 15.02.2024 12:04, Roger Pau Monné wrote:
>> On Thu, Feb 15, 2024 at 11:43:02AM +0100, Jan Beulich wrote:
>>> On 15.02.2024 11:28, Roger Pau Monné wrote:
>>>> Without the reordering the include of include/config/auto.conf will
>>>> always succeed on rebuilds, because the include is done before
>>>> executing the include/config/%.conf.cmd target that does the `rm`.
>>>
>>> That's a dual target: It also handles include/config/%.conf. I.e.
>>> because of this ...
>>>
>>>> With the current order the include of include/config/%.conf.cmd that
>>>> triggers the re-build of auto.conf happens after having included the
>>>> file already.
>>>
>>> ... either include would trigger this same rule. IOW I'm afraid I'm still
>>> not seeing what is gained by the re-ordering. I'm also unconvinced that
>>> "triggers" in the sense you use it is actually applicable. Quoting make
>>> doc again: "Once it has finished reading makefiles, make will try to
>>> remake any that are out of date or don’t exist." To me this means that
>>> first all makefile reading will finish, and then whichever included files
>>> need re-making will be re-made.
>>
>> Without the re-ordering the execution is not stopped on failure to
>> generate include/config/auto.conf:
>>
>> # gmake -j8 xen clang=y
>> gmake -C xen install
>> gmake[1]: Entering directory '/root/src/xen/xen'
>> rm -rf include/config/auto.conf
>> tools/kconfig/conf  --syncconfig Kconfig
>> common/Kconfig:2: syntax error
>> common/Kconfig:1: invalid statement
>> gmake[2]: *** [tools/kconfig/Makefile:73: syncconfig] Error 1
>> gmake[1]: Failed to remake makefile 'include/config/auto.conf'.
>>   UPD     include/xen/compile.h
>>  Xen 4.19-unstable
>> gmake[3]: Nothing to be done for 'all'.
>> [...]
>>
>> With the re-ordering:
>>
>> # gmake -j8 xen clang=y
>> gmake -C xen install
>> gmake[1]: Entering directory '/root/src/xen/xen'
>> rm -rf include/config/auto.conf
>> tools/kconfig/conf  --syncconfig Kconfig
>> common/Kconfig:2: syntax error
>> common/Kconfig:1: invalid statement
>> gmake[2]: *** [tools/kconfig/Makefile:73: syncconfig] Error 1
>> gmake[1]: *** [Makefile:379: include/config/auto.conf] Error 2
>> gmake[1]: Leaving directory '/root/src/xen/xen'
>> gmake: *** [Makefile:143: install-xen] Error 2
>> #
>>
>> So the re-ordering is meaningful.
> 
> Hmm, I was about to say "no, it isn't" but then remembered to try newer
> make. With 3.81 all is working as intended with no re-ordering. I wonder
> if this isn't something with make, rather than our makefiles ...

And indeed it's quite strange: The same effect can be had by dropping the
- from the other include (and no re-ordering). Extending the sub-make
invocation to

        $(Q)$(MAKE) $(build)=tools/kconfig syncconfig || { err=$$?; echo "$@: 
error $$err" >&2; exit $$err; }

I can see that it's the latter of the includes which is reported as $@,
and failure of the sub-make is conveyed only when it's the latter of
the includes which has no -. When really any of the targets being subject
of "include" without - should respect failure.

I'll play with this some more, but considering the overall situation
maybe (perhaps just partly) reverting the commit Anthony pointed out is
then the least bad option, accepting the warnings with old make.

Jan