public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ian Campbell <ijc@hellion.org.uk>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/4] kconfig: switch to single .config configuration
Date: Sat, 21 Feb 2015 10:38:26 +0000	[thread overview]
Message-ID: <1424515106.25370.68.camel@hellion.org.uk> (raw)
In-Reply-To: <CAMhH57Rt_WLFa1wX8bg1HDVf1QGrvj7-aLAK+f12+RO5Mr0oMA@mail.gmail.com>

On Sat, 2015-02-21 at 02:51 +0900, Masahiro YAMADA wrote:
> 2015-02-20 6:13 GMT+09:00 Stephen Warren <swarren@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.

  reply	other threads:[~2015-02-21 10:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19  7:55 [U-Boot] [PATCH v2 0/4] kconfig: turnaround into single .config Masahiro Yamada
2015-02-19  7:55 ` [U-Boot] [PATCH v2 1/4] ARM: UniPhier: set CONFIG_SYS_MALLOC_F to the global default value Masahiro Yamada
2015-02-19 18:28   ` Simon Glass
2015-02-19  7:55 ` [U-Boot] [PATCH v2 2/4] malloc_f: fix broken .config caused by CONFIG_SYS_MALLOC_F Masahiro Yamada
2015-02-19  7:55 ` [U-Boot] [PATCH v2 3/4] kconfig: switch to single .config configuration Masahiro Yamada
2015-02-19 21:13   ` Stephen Warren
2015-02-20 17:51     ` Masahiro YAMADA
2015-02-21 10:38       ` Ian Campbell [this message]
2015-02-24  6:16         ` Masahiro Yamada
2015-02-20 19:20     ` Simon Glass
2015-02-21  0:55       ` Masahiro YAMADA
2015-02-21  2:29         ` Simon Glass
2015-02-19  7:55 ` [U-Boot] [PATCH v2 4/4] kconfig: remove unneeded dependency on !SPL_BUILD Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1424515106.25370.68.camel@hellion.org.uk \
    --to=ijc@hellion.org.uk \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox