From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] How to handle modularity in buildroot?
Date: Tue, 4 Dec 2012 10:10:42 +0100 [thread overview]
Message-ID: <20121204101042.3ae057bb@skate> (raw)
In-Reply-To: <201212041249.14541.manningc2@actrix.gen.nz>
Dear Charles Manning,
On Tue, 4 Dec 2012 12:49:14 +1300, Charles Manning wrote:
> I am aware of this mechanism but I don't think it really gets me what I am
> after.
>
> I think that with defconfig, I would be able to make defconfig, then tweak the
> config to get a variant. But now if I change the base config, I then have to
> go through the process again for the variant.
>
> What I would like is the ability to have:
> * A base package
> * Production rootfs = base + production files.
> * Development rootfs = base + development files.
>
> Then a change to the base package automatically flows through the production +
> development rootfs.
>
> Is there a way to accomplish that?
First of all, thanks for your nice words about Buildroot, definitely
appreciated.
That said, if Buildroot is certainly simpler than OE, it also means
that Buildroot has a smaller feature set, and to some extent a bit less
flexibility.
What you can do to achieve what you want is use defconfig fragments.
For example:
* mysystem_base_defconfig.frag would contain:
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_PATH="/home/thomas/x-tools/arm-br-arm926/usr/"
BR2_TOOLCHAIN_EXTERNAL_LARGEFILE=y
BR2_TOOLCHAIN_EXTERNAL_INET_IPV6=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_BUSYBOX=y
* mysystem_prod_defconfig.frag would contain:
BR2_PACKAGE_APPLICATION1=y
BR2_PACKAGE_APPLICATION2=y
* mysystem_dev_defconfig.frag would contain:
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_LTRACE=y
And then, when you want to do a production build:
make clean
cat mysystem_base_defconfig.frag mysystem_prod_defconfig.frag > configs/mysystem_prod_defconfig
make mysystem_prod_defconfig
make
And when you want to do a development build:
make clean
cat mysystem_base_defconfig.frag mysystem_dev_defconfig.frag > configs/mysystem_dev_defconfig
make mysystem_dev_defconfig
make
Basically, instead of having Buildroot providing this feature, we rely
on the simple manipulation of the configuration file.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-12-04 9:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 22:00 [Buildroot] How to handle modularity in buildroot? Charles Manning
2012-12-03 23:17 ` ANDY KENNEDY
2012-12-03 23:49 ` Charles Manning
2012-12-04 9:01 ` Stephan Hoffmann
2012-12-04 9:10 ` Bjørn Forsman
2012-12-04 9:10 ` Thomas Petazzoni [this message]
2012-12-04 18:18 ` Charles Manning
2012-12-05 17:14 ` Arnout Vandecappelle
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=20121204101042.3ae057bb@skate \
--to=thomas.petazzoni@free-electrons.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox