Re: RFC: Support for U-Boot phases in Kconfig

From: Simon Glass <sjg@chromium.org>
To: Tom Rini <trini@konsulko.com>
Cc: "U-Boot Mailing List" <u-boot@lists.denx.de>,
	"Marek Vasut" <marex@denx.de>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Bin Meng" <bmeng.cn@gmail.com>, "Stefan Roese" <sr@denx.de>,
	"Marek Behún" <marek.behun@nic.cz>,
	"Sean Anderson" <seanga2@gmail.com>,
	"Aaron Williams" <awilliams@marvell.com>
Subject: Re: RFC: Support for U-Boot phases in Kconfig
Date: Wed, 11 Aug 2021 08:11:41 -0600	[thread overview]
Message-ID: <CAPnjgZ17eJf1z0_G2P3tN0DGtr+sdkzdzL_CRioZp7wbZS+AZA@mail.gmail.com> (raw)
In-Reply-To: <20210811140220.GX858@bill-the-cat>

Hi Tom,

On Wed, 11 Aug 2021 at 08:02, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Aug 11, 2021 at 06:56:31AM -0600, Simon Glass wrote:
> [snip]
> > Having thought a bit more, perhaps we have the wrong attitude to
> > Kconfig. The CONFIG() macro I am talking about works by building an
> > xxx or SPL_xxx config. If we have separate autoconf.h files for each
> > phase (autoconf_spl.h etc.) then we don't actually need this. We just
> > need to include the correct file. Any SPL_xxx config can be written as
> > xxx. Similarly the Makefile rules can drop the $(P) I was proposing.
> >
> > We can, in fact, generate separate autoconf.h files for each phase
> > today, with no other changes. Unless I am missing something...?
>
> If we can spit out {spl_,tpl_,}autoconf.h files that might help a bit.
> But would it help with the recent case of SPL has SATA+AHCI+!PCI while
> full U-Boot has SATA+AHCI+!PCI AND SATA+AHCI+PCI ?  Today we can't
> support the SPL case without adding the handful of SPL_xxx symbols so
> that we can say we have SATA+AHCI without PCI.

My thought is that:

- where there is no SPL_xxx symbol, it we would have CONFIG_xxx=y in
all autoconf.h files
- where there is an SPL_xxx symbol, it we would only have it in
spl_autoconf.h if the SPL_xxx symbol is enabled

So it does not reduce the power/flexibility of what we have to cover
all cases. It is just a phase-specific way of presenting the configs
to the build, so we can do:

obj-$(CONFIG_FOO) += foo.o

as well as

if (CONFIG(FOO))

I'm still thinking about Kconfig. To me it seems that separating the
phases so completely is giving up quite a bit. There is no-longer a
unified build, so dependencies between phases may become a problem. I
think in fact our problem is the use of SPL_ and TPL_ prefixes on
Kconfigs, which you have highlighted. Perhaps we just shouldn't do
that. It would be nice if kconfig could support multiple interrelated
build phases and output a separate autoconf.h for each one.

Regards,
Simon