CODEWITHSUNDEEP
yoctobitbakeopenembedded
Jan Hudec
Jan Hudec

Reputation: 76266

Best current practice on versioning Yocto layer set

Yocto has a set of independent repositories containing the base system (Poky) and various software components (all the meta-* repositories here, and also openembedded layer index). So when you want to build an image for specific device and purpose, you need a handful of repositories checked out.

These are all tied together by the conf/bblayers.conf and conf/local.conf files in the build directory. But that is a build directory—it is supposed to be disposable, containing only information that can be easily regenerated on request. And it does—except for the list of layers in conf/bblayers.conf and a couple of definitions like the MACHINE in the conf/local.conf that define the target system to build for.

How should I version this information?

Currently we have a rather hacky script that assembles the build directory and writes the config files, but it does not know how to properly update them when it changes.

So is there a better option? Preferably one that would avoid any additional steps between checkout/update (with submodules or repo), oe-init-build-env init script (which creates the build directory if it does not exist) and running bitbake with appropriate target image?

Upvotes: 2

Views: 1038

Answers (3)

d21d3q
d21d3q

Reputation: 385

What works for me is copying oe-init-build-env to project root directory, udpdating paths to correctly setup OEROOT and comenting out call to "$OEROOT"/scripts/oe-setup-builddir.

Project structure:

conf/
├─ local.conf
├─ bblayers.conf
layers/
├─ poky/
├─ foo/                  # custom layers
oe-init-build-env        # copied from layers/poky/oe-init-build-env

conf is checked into git repository, layers inside layers/ are added as submodules and its paths need to be set in conf/bblayers.conf

Modifications to oe-init-build-env:

if [ -z "$OEROOT" ]; then
    OEROOT=$(dirname "$THIS_SCRIPT")
    # OEROOT=$(readlink -f "$OEROOT")
    OEROOT=$(readlink -f "$OEROOT")/layers/poky. # this path updated
fi

# (...)

export OEROOT
. "$OEROOT"/scripts/oe-buildenv-internal 
# comment out call to oe-setup-builddir
#&&
#     TEMPLATECONF="$TEMPLATECONF" "$OEROOT"/scripts/oe-setup-builddir || {
#     unset OEROOT
#     return 1
# }
unset OEROOT

# (...)

# this is also not needed
#[ -z "$BUILDDIR" ] || cd "$BUILDDIR"

from now you can use bitbake from root of your project, and it will pick conf/local.conf

Upvotes: 0

Oleksandr Kravchuk
Oleksandr Kravchuk

Reputation: 6319

Actually, repo is a convenient tool for managing manifest files with all the needed repositories.

Then you can use TEMPLATECONF to version local.conf and bblayers.conf. Here is how we do it: https://pelux.io/software-factory/master/chapters/baseplatform/building-PELUX-sources.html

Upvotes: 1

rrerolle
rrerolle

Reputation: 1

The Poky distribution itself uses the Combo Layer tool, which seems to be designed to address this particular problem. However, it's not very clear what the workflow is supposed to look like, when using this tool.

Regarding the default bblayers.conf and local.conf files, you can either version them anywhere in your project and have a script copy them in your build folder after calling oe-init-build-env, or simmply use meta-poky/conf/bblayers.conf.sample and meta-poky/conf/local.conf.sample, which are automatically installed by oe-init-build-env when first creating the build directory.

Now, when you make changes or add layers, you will have to clear the build directory for the changes in the .sample files to take effect.

Upvotes: 0

Related Questions