[yocto] Layer manifest (topic touched at ELCE)

Trevor Woerner twoerner at gmail.com
Wed Jan 6 17:43:58 PST 2016


On 01/06/16 17:42, Mark Hatle wrote:
> But using a combination of the defined dependencies and the layer index you
> should be able to resolve "known" layers.  (Would also be nice if the index
> looked for collisions as well...)

I wrote a silly script[1] that probes the layer index and presents the
user with a list of MACHINES. The user chooses and MACHINE and, based on
the dependencies of the BSP layer defining that machine, the script
pulls in all the required layers and updates the conf/bblayer.conf file.
So basically the user just picks a MACHINE and the script does the rest
so all the user then has to do is type "bitbake <image>". It was just a
silly little proof of concept. It's not perfect, but it does work for me
and I do use it all the time. Of course, it makes assumptions with which
others might not agree ;-) ndec tried it and said it didn't work for
him; yymv. The point is the data is out there (in the layer index) and
it's not too hard to just choose a machine and let the computer pull the
layers and update your config. The thing is... IMHO the layers are
_almost_ a foreign part of the entire build process. IMHO they're
_almost_ like a second-class citizen.

I'm not trying to complain.

But it's not just layers, the whole process of setting up your
configuration is a bit of a mess! I've tried floating the idea (maybe it
was at ELCE?) that maybe the configuration files should be more unified?
Wouldn't it be great if I could give you one configuration file and with
it you could type "bitbake <image>" and it would do all the work of
pulling in the layers, the layer dependencies, maybe even specify
specific checkouts of those repositories, it would specify all the bits
you need, and then build your image? In many cases builds only succeed
when specific checkouts of specific layer repositories are used with
specific configuration incantations in specific configuration files.
It'd be nice to be able to specify all the things you need to re-create
my build in one config file.

It seems awkward that I can checkout the yocto layer and build
core-image-x11 as-is, but if I want to build core-image-wayland then I
have to edit conf/local.conf and rejigger a bunch of configuration
parameters before it'll work. If specific DISTRO_FEATURES are required
for an image to build, they should be in the image configuration file,
no? The build shouldn't rely on me correctly adjusting my local.conf to
make it work?

If I perform a build today and want to save <something> so that I can
have some hope of being able to recreate that build at some point in the
future I have to save: auto.conf, local.conf, bblayers.conf, then, for
each layer, I have to record what the HEAD was for its repository as
well as where I got every layer from (there are several github layers,
for example, with the same name).

:-)

The arguments against this panacea ;-) revolve around the need to keep
the build system as flexible as possible. It is argued that each part of
the build process should be independent and therefore be independently
configurable.

Circling back to your email, a layer manifest for a BSP should specify
all layer dependencies, specify where to find those layers (and maybe
even suggest which branches/checkouts to use?), in such a way that the
build could use it automatically without expecting the user to find,
checkout, and update bblayers.conf manually.

Maybe this discussion would be better on oe-architecture?















[1] https://github.com/twoerner/oe-layerindex-config



More information about the yocto mailing list