On Wed, Aug 11, 2021 at 08:11:41AM -0600, Simon Glass wrote: > 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.
What are the dependencies we have between phases? You've mentioned bloblist, but to me that's like BOARD_INIT and MISC_INIT_R and all of the other things you need to have select'd on a platform because they're non-optional. And I'm really not seeing now how we would support the example I gave as for them SPL with SATA+AHCI+PCI is not desired nor possible. I asked. The answer was no, don't want it. Or do you really just mean that if we had spl_autoconf.h the only thing that would change is that we would never test on CONFIG_SPL_xxx only CONFIG_xxx, but we would still need to Kconfig SPL_xxx? -- Tom
signature.asc
Description: PGP signature