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.
Ian.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
