Hi Ian,
On Sat, 21 Feb 2015 10:38:26 +0000 Ian Campbell <i...@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 <swar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
