Hi Tom, On Wed, 11 Aug 2021 at 08:02, Tom Rini <tr...@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