Why does the yocto bblayers.conf file use absolute paths?

Question

The yocto project allows you to use the relative path in most of your configuration files, but not in the ./build/conf/bblayers.conf file. What is the reason for blocking the use of anything other than absolute paths for the BBLAYERS and BBLAYERS_NON_REMOVABLE ?

I reviewed the BitBake user guide for yocto version 2.0 (current version), but this does not explain the reasoning. I also checked some of the older versions of the manual, but they don't seem to mention the reasoning when talking about the bblayers.conf file or the BBLAYERS variable. The same file contains BBPATH = "${TOPDIR}" , which is at least dynamically assigned and is not far from the yotco root directory.

My best guess is that the bblayers.conf file is specific to the system on which it is running. This would make it unsuitable for sharing between developers through source control, and absolute paths would force people to edit the file whenever they received a copy. This, however, is not a good reason, so the question is.

Answer 1

All existing answers answer "how to use relative paths", but the question is "why are absolute paths used." As far as I know, the “why” is simple, this is done so that the assembly directory can be moved anywhere in the file system. Think about it: you can get poky / oe-init-build-env from anywhere in the file system and the build directory will be created there, so using paths relative to the build directory is very fragile.

Edit:

maybe this is clearer, I think you assume that the bblayers.conf file is always in poky/build/conf/bblayers.conf , and so you can use a path like ../../meta-layer-foo , to refer to some layer that will be in poky/meta-layer-foo , but the layer will not be found if I create an instance of "build" in another poky/foo/bar path:

 etienne@ubuntu :~/repos/poky-tx2$ mkdir -p foo/bar etienne@ubuntu :~/repos/poky-tx2$ cd foo/bar/ etienne@ubuntu :~/repos/poky-tx2/foo/bar$ ls etienne@ubuntu :~/repos/poky-tx2/foo/bar$ source ../../oe-init-build-env You had no conf/local.conf file. This configuration file has therefore been created for you with some default values. You may wish to edit it to, for example, select a different MACHINE (target hardware). See conf/local.conf for more information as common configuration options are commented. You had no conf/bblayers.conf file. This configuration file has therefore been created for you with some default values. To add additional metadata layers into your configuration please add entries to conf/bblayers.conf. The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ ### Shell environment set up for builds. ### You can now run 'bitbake <target>' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' etienne@ubuntu :~/repos/poky-tx2/foo/bar/build$ ls conf 

Answer 2

I found a way to use relative paths.

You can use the built-in python to move the file system. The following script uses the provided TOPDIR variable and then navigates to its parent via python os.path api.

 # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly LCONF_VERSION = "6" BBPATH = "${TOPDIR}" BBFILES ?= "" YOCTOROOT = "${@os.path.abspath(os.path.join("${TOPDIR}", os.pardir))}" BBLAYERS ?= " \ ${YOCTOROOT}/poky/meta \ ${YOCTOROOT}/poky/meta-yocto \ ${YOCTOROOT}/poky/meta-yocto-bsp \ " BBLAYERS_NON_REMOVABLE ?= " \ ${YOCTOROOT}/poky/meta \ ${YOCTOROOT}/poky/meta-yocto \ " 

References

• OpenEmbedded bitbake.conf
• Extended functionality with python
• How to get parent directory in Python?

Answer 3

I managed to get the "relative paths" in the bblayers.conf files working by replacing

 BBLAYERS ?= " \ /home/username/poky/meta \ ... 

with

 BBLAYERS ?= " \ ${TOPDIR}/../meta \ ... 

I believe one of the caveats with this approach is that I rely on meta-XXX layer directories that are always in the TOPDIR parent folder. This is similar to the default way to use yocto, but it may not be the case for more custom build settings.

Answer 4

You can use relative paths in bblayers.conf .

Probably this line in your bblayers.conf :

 BBPATH = "${TOPDIR}" 

If you want to know this variable content, you will probably find the top level directory in the assembly directory:

 bitbake -e | grep ^TOPDIR # searches for bitbake variables 

Inside this directory, you can create a meta-test layer and add it to bblayers.conf with a relative path:

 BBLAYERS ?= " \ meta-test \ [...] " 

So, the answer to your question why there are absolute paths in bblayers.conf , is that you can place the assembly directory anywhere in the system and independent of Yocto.

Relative paths to layers should always refer to the assembly directory.

Answer 5

I am working with the Rocko version and my bblayers.conf file also does not support relative paths. I tried to modify the bblayers.conf file using the TEMPLATECONF variable. The TEMPLATECONF variable points to a directory containing bblayers.conf.sample , layer.conf and local.conf.sample . I exported the TEMPLATECONF variable to get the necessary bblayers.conf and local.conf in the assembly directory, but in my bblayers.conf.sample variable was set in a relative way, as shown below:

 BBLAYERS ?= " \ ##OEROOT##/meta \ ##OEROOT##/../meta-xilinx \ ##OEROOT##/../meta-xilinx-tools \ ##OEROOT##/../meta-openembedded/meta-oe \ ##OEROOT##/../meta-openembedded/meta-perl \ ##OEROOT##/../meta-openembedded/meta-python \ ##OEROOT##/../meta-openembedded/meta-multimedia \ ##OEROOT##/../meta-openembedded/meta-networking \ ##OEROOT##/../meta-openembedded/meta-filesystems \ ##OEROOT##/../meta-openembedded/meta-webserver" 

but this does not seem to work. The OEROOT variable could not set the correct paths. One reason may be that when the oe-init-build-env script ends, it resets the OEROOT variable. Although, if you manually export the OEROOT variable to the value you need, this may help. However, when I changed the OEROOT variable to TOPDIR , it worked like a keychain, as shown below:

 BBLAYERS ?= " \ ${TOPDIR}/../meta \ ${TOPDIR}/../meta-poky \ ${TOPDIR}/../meta-skeleton \ ${TOPDIR}/../meta-selftest \ ${TOPDIR}/../meta-yocto-bsp \ ${TOPDIR}/../../meta-xilinx/meta-xilinx-bsp \ ${TOPDIR}/../../meta-xilinx/meta-xilinx-contrib \ ${TOPDIR}/../../meta-xilinx-tools \ ${TOPDIR}/../../meta-openembedded/meta-oe \ ${TOPDIR}/../../meta-openembedded/meta-perl \ ${TOPDIR}/../../meta-openembedded/meta-python \ ${TOPDIR}/../../meta-openembedded/meta-multimedia \ ${TOPDIR}/../../meta-openembedded/meta-networking \ ${TOPDIR}/../../meta-openembedded/meta-filesystems \ ${TOPDIR}/../../meta-openembedded/meta-webserver" 

Which probably makes me think that the failure of the OEROOT variable by the oe-root-init-env script caused the problem. Also, if someone finds a better solution, please respond.