All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.