Re: [for-4.19][PATCH] build: Allow setting KBUILD_DEFCONFIG in the environment

[Jan Beulich <jbeulich@suse.com>]

On 25.10.2023 11:35, Michal Orzel wrote:
> 
> 
> On 25/10/2023 11:26, Jan Beulich wrote:
>>
>>
>> On 25.10.2023 11:21, Michal Orzel wrote:
>>> On 25/10/2023 11:10, Jan Beulich wrote:
>>>> On 25.10.2023 10:28, Michal Orzel wrote:
>>>>> At the moment, in order to use a different defconfig target than default,
>>>>> one needs to specify KBUILD_DEFCONFIG=<target> on the command line.
>>>>> Switch to weak assignment, so that it can be also obtained from
>>>>> environment similar to other KCONFIG/KBUILD variables.
>>>>>
>>>>> This change will activate the use of KBUILD_DEFCONFIG variable in CI
>>>>> build jobs that so far had no effect.
>>>>
>>>> I'm certainly okay with the change, but the above sentence looks misleading
>>>> to me: Yes, the envvar was ignored so far, but isn't it the case that the
>>>> envvar as specified in CI matches what Makefile set it to (taking into
>>>> account that for RISC-V riscv64_defconfig aliases tiny64_defconfig), and
>>>> hence the specifications in build.yaml could be dropped (until such time
>>>> where truly an override was intended)?
>>> Well, today riscv64_defconfig matches tiny64_defconfig but it can change. Otherwise, why
>>> would we need to have 2 identical files? Looking at the latest full build series from Oleksi,
>>> only the tiny64_defconfig file gets updated which would be the clear indication that what is
>>> specified in the CI matches the author's expectation.
>>>
>>> Also, I never mentioned that this change fixes something. I just wrote that it gives a meaning
>>> to a variable that so far had no effect.
>>
>> Well, sure, but if you e.g. said "... that so far would have had no effect
>> if they didn't match the default anyway", things would have been unambiguous.
> Ok, I can see you did not provide any tag in which case I will wait for other's feedback.
> Then, I can either respin the patch adding sentence you suggested or leave it to Stefano
> to do when committing to his for-4.19 branch.

The reason I didn't offer A-b (yet) is that with the given description plus
the claim on Matrix by someone that things don't work because of this
override not working, it wasn't really clear to me whether that claim was
wrong, or whether my view of the situation is. In the latter case I could
hardly ack the patch, as that would then mean I'd ack something I don't
understand. Provided there really has not been any breakage so far because
of this, feel free to add
Acked-by: Jan Beulich <jbeulich@suse.com>
preferably with the slightly adjusted description.

Jan