[Openembedded-architecture] bblayers.conf - Past, Present and Future?
Trevor Woerner
twoerner at gmail.com
Thu May 12 13:08:14 UTC 2016
On Thu 2016-05-12 @ 01:59:15 PM, Jan-Simon Möller wrote:
> I have another use-cases:
> 5) allow fetched layers to be optional (not added to bblayers.conf)
> - we could build several boards based on the same checkout with
> different layer configurations (e.g. add remove a BSP)
I agree 100% with this sentiment... or at least I used to, now I only agree
with it 90% ;-) The way I've used OE up to this point is exactly what you've
pointed out: a person wants to build an image for a given machine.
I'm not fond of Angstrom because I don't like the idea that it grabs ~40(?)
layers and then starts a built for 1 MACHINE which only really needs maybe 3
of them (?). And I'm not entirely fond of the way Linaro does their RPB either
for the same reason (although at this rate the two are basically converging
into each other).
I often try to start an Angstrom build and then have to go into bblayers.conf
to disable a bunch of layers because they don't "play nice" with each other.
Of course bitbake only tells me about them one at a time, so I end up having
to 1) start a build 2) get an error from bitbake about a bad layer 3) edit
bblayers.conf 4) goto 1. I usually go through this cycle about 5-6 times, then
my build can proceed (once the 5-6 bad layers have been weeded out).
It's not Angstrom's fault, of course. But what was recently pointed out to me
is: OE is a distro tool, not an image creation tool. As a distro you want a
setup that contains dozens of BSP layers.
If you grab oe-core, a BSP layer, maybe meta-oe, and maybe a distro layer
you're using OE as an image creation tool. That's exactly how I've been using
it up to this point. Is that wrong? Is that a bad thing?
More information about the Openembedded-architecture
mailing list