[bitbake-devel] Multi-configuration builds

[Trevor Woerner]

On Fri 2016-06-10 @ 05:13:43 PM, Richard Purdie wrote:
> On Fri, 2016-06-10 at 12:07 -0400, Trevor Woerner wrote:
> > On Fri 2016-06-10 @ 04:33:29 PM, Richard Purdie wrote:
> > > A few people have asked about multi-machine builds.
> > 
> > Do you envision each config also pointing to individual bblayer
> > configurations
> > too? I.e. if I'm building for 3 different MACHINEs, with 3 different
> > configs
> > (local.conf?), then there would also be 3 different bblayers.conf's?
> 
> 
> No, there is one local.conf and one bblayers.conf file and then three
> different multiconfig files, each one of which sets a different
> MACHINE.
> 
> Would people really want to support different bblayer files? That would
> complicate things quite a lot :/.

Personally I have a common "Downloads" directory (this is probably quite normal).

Then, I have a common "layers" directory in which I checkout every layer of
which I'm aware. I also have a script that I run manually from time to time to
keep each layer up to date (although it's capable of running any general git
command on each git repository it finds one level beneath it):
	https://github.com/twoerner/oe-misc/blob/master/scripts/gitcmd.sh

I then create separate directories for each platform for which I'm interested
in building (e.g. raspi2, raspi3, minnow, dragon, etc...). In each of those
directories I have separate local.conf, bblayers.conf, sstate-cache, and tmp
directories.

I know most will disagree with this arrangement (especially the separate
sstate-cache directories) but it's a system that has evolved over time, each
decision was made based on experience, and it works great for me!

It's been my experience that having too many layers in a build slows down the
initial parsing stage noticeably and too often layers don't play well with
each other. Also *many* build issues after an update can be fixed by blowing
away tmp *and* sstate and starting over. Often, building for a particular
board requires particular tweaks to local.conf (whether to enable a vendor
license or to enable specific hardware/features) which don't apply to other
boards and builds.

I'm happy with the speed of my builds, and I have enough disk space to
maintain the multiple sstates/tmps/etc. *Most* of my builds are
core-image-full-cmdline-type builds and I can crank one of those out from
scratch in 20 minutes (assuming the majority of sources have already been
downloaded). Although I do sometimes need chromium (which takes an hour on its
own) and I used to do qt (which is also quite painful). So I can understand
how sstate might be more useful to others, but for me, not so much.