From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] Project configuration management
Date: Wed, 6 Apr 2016 13:01:45 -0300 [thread overview]
Message-ID: <570532E9.6040401@zacarias.com.ar> (raw)
In-Reply-To: <20160406165217.07547fff@free-electrons.com>
On 06/04/16 11:52, Thomas Petazzoni wrote:
> That's not exactly the sort of script I was thinking of. I was thinking
> of a more high-level, project specific script, like maybe:
>
> genconfig -h <hwplatform> -s <softwarestack> -r <releasetype>
>
> or anything like that, which would internally have the knowledge of
> which fragments to use for which aspect (HW platform, software stack,
> etc.). Of course, internally, this script can use merge_config.sh, but
> having a more high-level script might help users to more easily
> generate their Buildroot configuration.
>
> Thomas
Hi.
Adding a bit on this since you CCed me, this customer has multiple
platforms (boards/architectures), with multiple capabilities (different
video in/out frontends) and localized features.
What i've used is pretty much what Thomas says, a script that takes
several parameters as input:
genconfig -p platform -b build_type -c capabilities -l localization ...
Where platform would be different hardware targets, build_type is what
kind of rootfs/image/firmware it's building (debug, release, etc), which
capabilities (isdb-t, dvb-s2, etc), and which localization (target
country, for language, menus, logos, etc).
The script then combines different defconfig fragments according to
these parameters and validates the different combinations (for instance
some platform X can't have isdb-t or so on), generating a suitable
defconfig and setting up an out-of-tree build ready to go.
Of course the "chunkization" of the defconfig fragments requires some
knowledge, but it essentially boils down to:
* Hardware platform
+ Toolchain setup (varies for debug & release)
+ Target filesystem setup (might be different for debug & release)
+ Kernel setup (ditto above)
* Apps
+ Open-source apps for the target (might vary for debug & release)
+ Propietary apps (varies according to capabilities and localization)
* Localization
+ Language packs, certificates, default settings, marketing stuff, etc
Regards.
next prev parent reply other threads:[~2016-04-06 16:01 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
2016-04-05 11:14 ` Mateusz Słupny
2016-04-06 14:52 ` Thomas Petazzoni
2016-04-06 16:01 ` Gustavo Zacarias [this message]
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=570532E9.6040401@zacarias.com.ar \
--to=gustavo@zacarias.com.ar \
--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.