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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.02.2024 18:23, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 05:22:00PM +0100, Jan Beulich wrote:
>> On 15.02.2024 17:08, Roger Pau Monné wrote:
>>> On Thu, Feb 15, 2024 at 02:02:41PM +0100, Jan Beulich wrote:
>>>> --- a/xen/Rules.mk
>>>> +++ b/xen/Rules.mk
>>>> @@ -15,7 +15,11 @@ srcdir := $(srctree)/$(src)
>>>>  PHONY := __build
>>>>  __build:
>>>>  
>>>> --include $(objtree)/include/config/auto.conf
>>>> +ifneq ($(obj),tools)
>>>> +ifneq ($(obj),tools/kconfig)
>>>> +include $(objtree)/include/config/auto.conf
>>>> +endif
>>>> +endif
>>>
>>> Trying to understand this, I assume it's to avoid an infinite
>>> dependency loop that generating include/config/auto.conf requires some
>>> tools that are build using xen/Rules.mk?
>>
>> The file has dependencies only in xen/Makefile. This is about the
>> file simply not being there when initially building. Perhaps the
>> patch description helps that I've written in the meantime:
>>
>> "Because of using "-include", failure to (re)build auto.conf (with
>>  auto.conf.cmd produced as a secondary target) won't stop make from
>>  continuing the build. Arrange for it being possible to drop the - from
>>  Rules.mk, requiring that the include be skipped for tools-only targets.
> 
> Wouldn't it be more reliable if we skipped the include for any paths
> in $(obj) that start with 'tools', rather than hardcoding 'tools' and
> 'tools/kconfig'?

I was first meaning to do so, but the expression would end up more
complex than I'd like (for it needing to be an exact match of "tools"
and a prefix match of "tools/"). Thinking of it,

ifneq ($(obj),tools)
ifneq ($(patsubst tools/%,$(obj)),)

might do (and not be as complex as I first thought, when intending to
put all in a single "if").

Yet then it's not entirely impossible that we might gain a build tool
which is actually to be built after .config was (re)generated, i.e.
in the know of the target configuration. Thoughts?

Jan