[Buildroot] [External] Re: Linux arch default cfgs and fragments

Matthew Weber matthew.weber at collins.com
Mon Apr 29 15:21:17 UTC 2019

On Mon, Apr 29, 2019 at 9:51 AM Arnout Vandecappelle <arnout at mind.be> wrote:
> On 29/04/2019 16:39, Matthew Weber wrote:
> [snip]
> > I was just curious if we can make the use of fragments a bit more
> > foolproof as options get dropped and you have to watch the warnings to
> > catch when they do.
>  OK, so your suggestion is to add a check that after fragments have been
> applied, the resulting .config indeed contains the contents of the fragments.
> Similar to the check we have in e.g. test-pkg for SKIPPED.
>  The question is: do you want to make this an error or a warning? I think we
> can't make it an error, because there are use cases where you expect the
> fragment not to apply. I don't have a concrete example for the kernel config,
> but for Buildroot configs I have some fragments that I sometimes use that set
> defaults for some string options (e.g. for kernel defconfig to use), and that
> only really apply to the defconfig in which the kernel is built, but that gets
> applied everywhere (i.e. for all defconfigs for that particular board). So I'd
> have four defconfigs for four different configurations which are independent of
> the board, and then four config fragments for four different board types, with a
> total of sixteen different .config files, but only four of those actually have a
> kernel.

Agree, the script already makes the check optional through how you
provide arguments.  I think it would just be modifying how the kconfig
infra uses the script to merge.

>  Anyway, my point is: we can't really predict what the use case for config
> fragments is, so we can't make it an error.
>  And I do think it's already a warning. But of course, that warning gets
> completely lost in the build log.


>  In general, I think managing config fragments is far out of scope for
> Buildroot. We might add some tools to make managing them easier (without
> enforcing a particular workflow) but even that is a bit out of scope IMO. The
> <pkg>-diff-config target from almost a year ago that is still floating around on
> patchwork is already borderline IMO.

Agree.  Was just hoping to cleanup how we do merges as there are
errors introduced occasionally that aren't noticed until you have a
build in the lab.  If I can prevent that from occurring, I'll try :-)


More information about the buildroot mailing list