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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 25 Oct 2023, Jan Beulich wrote:
> 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@xxxxxxxx>
> preferably with the slightly adjusted description.

Added to for-4.19 with the adjusted commit message