How to manage meta layers for a yocto project & build configs in git

Question

I am trying to figure out a workflow for yocto based project. Currently I have created a git with submodule for each meta layer that I pull. https://github.com/shrkamat/rpi/tree/thud

This would mean when I move to a new yocto release (say warrior) I need to create new git branch & move all my submodule to track to new lease branch. Is there a better approach, are there any best practices here ?

Betrothal

I prefer google repo to handle multiple git repositories, you can see Freescale example. (But gitsm is ok too) – Forlini

Answer 1

These days, there are three major solutions (and best practises) to this problem, along with many, many homegrown scripts. If you're just starting out, I'd strongly suggest to stick to one of the following:

1) kas: a tool specialized in setting up an OpenEmbedded-based (and therefore, also poky-based) build, including checking out specific layer revisions, adding them to bblayers.conf, setting up local.conf, and starting bitbake for a specific target.

Pro:

• highly specialized, doesn't require working around hassles because it was meant for something else originally.
• supports bundling the build configuration with a layer, usually the product application. This can noticeably reduce commit cluttter.
• only solution with proper local.conf support

Contra:

• requires at least a functional python setup if is is pulled from pip, or docker plus a wrapper script.
• no functionality beyond setup and build

2) repo: a true classic by now, coming from the android world.

Pro:

• Extremely powerful, has a lot of built-in support for managing the pulled stuff - in this case, the layers.
• well known, highly tested.

Contra:

• getting things done beyond the layer setup itself requires a certain amount of trickery
• requires at least to be downloaded once.

3) git submodules: the lightweight approach.

Pro:

• usually requires no additional setup, we all have git readily installed, right?

Contra:

• least powerful approach, in my opinion.
• requires trickery or custom scripting to get anything done beyond the pure layer setup. Even more of it than repo.

So which to pick? My personal favorite is 1 - kas, as it fits my requirements almost perfectly. Your mileage might vary, as they say. But each of those general approaches is certainly a better start than doing homegrown scripts.

Carnify