From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Project configuration management
Date: Mon, 4 Apr 2016 22:45:45 +0200 [thread overview]
Message-ID: <5702D279.3050904@mind.be> (raw)
In-Reply-To: <20160404204429.472fb279@free-electrons.com>
On 04/04/16 20:44, Thomas Petazzoni wrote:
> Hello Mateusz,
>
> On Mon, 4 Apr 2016 15:55:44 +0200, Mateusz S?upny wrote:
>
>> We are using buildroot for building a series of projects. What I feel
>> is missing in buildroot is a way to store different configurations in
>> scope of a single project. For example, we would like to prepare
>> three types of builds, let's name them "Release", that is the basic
>> build, "Develop", that is a Release build + dropbear + some other
>> utilities, and "Extra", that contains all configuration options from
>> Develop + some additional tools (gdb, valgrind, etc.). To achieve
>> that, we have to maintain total of (number of projects) x (number of
>> build types) different configuration files that are almost identical.
>>
>> Can this goal be achieved without using multiple defconfig files that
>> share approx 90% of their contents? What would you advise to avoid
>> that?
>>
>> First solution that comes to my mind is to allow nesting defconfig
>> files with some include/source statement, but AFAICS that's not
>> supported.
>>
>> Please note that we are aware of "layered customizations" concept,
>> and we're using it to some degree, but it doesn't solve all the
>> issues, e.g. setting toolchain, selecting packages, and setting
>> multiple paths to layers itself has to be done in defconfig files
>> anyway.
>
> The mechanism we typically advise in such situation is to use defconfig
> fragments, and assemble them as needed to create the configuration you
> feed into Buildroot. A shell script (or other) can help generating the
> configuration fed into Buildroot from the fragments.
And that shell script exists already: support/kconfig/merge_config.sh
The main difficulty with this model is that there is no simple way to split
configs. Fortunately, for buildroot this is typically not much of a problem,
because your fragments will just add some packages.
Regards,
Arnout
>
> I'm Cc'ing Gustavo, who has been using this model for quite some time
> for a large project that involves multiple HW platforms, I'm sure he
> can give more insights on how to achieve that.
>
> Best regards,
>
> Thomas
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
next prev parent reply other threads:[~2016-04-04 20:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 13:55 [Buildroot] Project configuration management Mateusz Słupny
2016-04-04 18:44 ` Thomas Petazzoni
2016-04-04 20:45 ` Arnout Vandecappelle [this message]
2016-04-05 11:14 ` Mateusz Słupny
2016-04-06 14:52 ` Thomas Petazzoni
2016-04-06 16:01 ` Gustavo Zacarias
2016-04-04 19:09 ` Grant Edwards
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=5702D279.3050904@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.