[Openembedded-architecture] bblayers.conf - Past, Present and Future?

Trevor Woerner twoerner at gmail.com
Wed May 11 17:09:49 UTC 2016


I'm happy to see this topic come up, that others are interested in it, and
that others even have various tools and whatnot they've developed.

I too have written and played with several tools around this topic as well.
One of which was a python tool that would pull down the raw data from the
layerindex, parse it, and present it so the user could select their branch,
MACHINE, DISTRO, etc and it would generate the bblayers.conf for them.

So the user would say they want to build for master, choose a machine (say
cubietruck), the select Poky. The tool would then know to grab meta-sunxi,
meta-poky/meta-poky, and whatever layers those layers depended on, and get
started. That's how I noticed:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7852

Another snag was that bitbake-layers will only append to a bblayers.conf
file that is already working. I.e. it doesn't have the ability to start with
an empty file (or almost empty file) and generate the boilerplate and first
entries on its own. I ended up hacking up a version of bitbake-layers for
myself that would... but it stopped working a couple weeks ago and I haven't
had the time to investigate it yet.

I brought up this topic at the recent ELC2016 OE BoF and got lots of great
feedback from the audience. dvhart in particular (I hope he doesn't mind me
mentioning his name) mentioned a tool he had written to parse json files to do
this same thing:
	git.infradead.org/users/dvhart/bs.git

To add a point that I don't think anyone has mentioned yet, to bring this tool
full-circle it would be nice if builds by default would output "what they just
did". In other words the buildhistory's metadata-revs is a nice idea but it
doesn't record from where you pulled your various layers. Ideally one person
could perform a build, take this "layer output file", give it to someone else,
and they'd be able to reproduce the build with the same layers from the same
places, etc. Of course it wouldn't be able to account for local modifications,
but for now just noting "i used this repository's <something> branch, but it
had modifications" would be an okay start.



More information about the Openembedded-architecture mailing list