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.
~Michal
