[PATCH] kconfig: Proposed language extension for multiple builds

[Tom Rini]

On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote:
> On Sun, Feb 26, 2023 at 11:04 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Masahiro,
> >
> > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada <masahiroy at kernel.org> wrote:
> > >
> > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > +Masahiro Yamada
> > >
> > >
> > >
> > >
> > > I do not know.
> > > This seems a shorthand in Kconfig level.
> > >
> > >
> > > masahiro at zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc
> > >     540    1080   24872
> > > masahiro at zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc
> > >     163     326    7462
> > >
> > > If hundreds of duplications are not manageable,
> > > go for it, but kconfig will be out-of-sync from the
> > > upstream Kconfig.
> >
> > Yes that's right, it is a shorthand in Kconfig.
> >
> > The counts above understand the problem a little since quite a few
> > CONFIG options without an SPL prefix are used in SPL. We don't have
> > tools to estimate how many, and we sometimes add a new symbol to 'gain
> > control' of a particular feature in a phase.
> >
> > My intent in sending this patch was to check whether this support for
> > configuring multiple related builds (or something like it) could go
> > upstream, which for Kconfig is Linux, I believe. What do you think?
> 
> 
> This complexity is absolutely unneeded for Linux.
> 
> So, the answer is no.

Well, I think Simon summarized himself a bit shorter here than he did in
the patch itself.  So, to what extent does the kernel want to consider
all of the other projects using the Kconfig language and their needs /
use cases?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230226/51e3fd83/attachment.sig>