[U-Boot] [PATCH v2 3/4] kconfig: switch to single .config configuration

[Masahiro Yamada]

Hi Ian,


On Sat, 21 Feb 2015 10:38:26 +0000
Ian Campbell <ijc at hellion.org.uk> wrote:

> On Sat, 2015-02-21 at 02:51 +0900, Masahiro YAMADA wrote:
> > 2015-02-20 6:13 GMT+09:00 Stephen Warren <swarren at wwwdotorg.org>:
> > > On 02/19/2015 12:55 AM, Masahiro Yamada wrote:
> 
> > > I think the above patch demonstrates the problem very nicely; it changes the
> > > semantics from having CONFIG_USE_PRIVATE_LIBGCC enabled only in SPL build to
> > > having it enabled everywhere. While that particular change shouldn't be an
> > > issue, I think that requiring that all config options to have the same value
> > > in main/SPL/TPL will be.
> > 
> > Right.  This is the disadvantage of the single .config strategy.
> > That's why I chose separate .config at first.
> 
> Just a random thought, maybe it's unworkable, but...
> 
> Would it be possible to retain the 2x .config schema but only ever
> require the user to edit the top level one? For example by having every
> fooconfig target do something like:
> 
>         run fooconfig on top level .config as normal
>         ( echo CONFIG_SPL_BUILD=y ; cat .config ) > spl/.config
>         make -C spl <some-sort-of-forced-update>
> 
> IOW whenever the user changes .config it is automatically propagated to
> the spl (or tpl) .config, so we have 2x .config but one of them is
> non-user-serviceable.
> 
> That falls apart for "vi .config" though, so perhaps the echo+cat
> +forced-update would be better done as part of the recursion into
> spl/tpl at build time.



Thanks for your comments.

Actually, I posted a similar idea before:
http://lists.denx.de/pipermail/u-boot/2014-May/180357.html

This series adopted
the single editable .config  + forcible-update for SPL/TPL
as you suggested.


As for boolean options, it can enable or disable particular options for SPL/TPL.
But it cannot set hex or int type options independently.

So, I think we still have CONFIG_SYS_TEXT_BASE, CONFIG_SPL_TEXT_BASE, CONFIG_TPL_TEXT_BASE
for example.


I do not think this way has significant advantages against the pure single .config strategy.



Best Regards
Masahiro Yamada