Login/Register
Why does the yocto bblayers.conf file use absolute paths?
Asked Answered
Solved configuration-filesabsolute-pathyoctobitbake
R

6

16

The yocto project allows the use of relative path in most of its configuration files but not within the ./build/conf/bblayers.conf file. What is the reason for blocking the use of anything but absolute paths for the BBLAYERS and BBLAYERS_NON_REMOVABLE variables?

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

My best guess is that the bblayers.conf file is specific to the system it is being run on. That would make it unsuitable for sharing between developers via source control and the absolute paths would force people to edit the file whenever they received a copy. That did not seem like a very good reason though, hence the question.

Reviewer answered 11/8, 2016 at 8:11 Comment(4)
Did you ever figure out how to do it? Sitting in the same boat right now :) – Gigi
@MarioTacke no I did not. I think the answer is that the bblayers.conf file is intended to be specific to a user on a machine and only temporary. Once you have sorted out what layers you want, you should make a recipe that replaces most of the bblayers.conf contents. You can use ${HOME}, ${TOPDIR} and a few other substitutions but not relative paths. – Reviewer
No one is answering the question. I am not asking "How do I use relative paths" I am asking "Why is their use blocked". Looking back at this now I am guessing that the answer is for efficiency. For an absolute path you can navigate directly to the target file. For a relative path you have to work out a present working directory, work out what is N lots of ../above it and move there, then move back down another directory path. That sounds like more work than go to /home/TafT/yocto/meta. – Reviewer
@Reviewer I added one answer trying to answer "why". – Yeld
J
3

All the existing answers are answering "how to use relative paths" but the question is "why are absolute paths used". As far as I know the "why" is simple, it is done that way so that the build directory can be moved anywhere on the filesystem. Think about it: you can source poky/oe-init-build-env from anywhere on the filesystem and the build directory will be created there, so relying on paths relative to the build directory is very fragile.

Edit:

maybe this is clearer, I think you are assuming that the file bblayers.conf is always in poky/build/conf/bblayers.conf and that you can therefore use a path like ../../meta-layer-foo to refer so some layer which would be in poky/meta-layer-foo, but the layer will not be found if I instantiate "build" in another path poky/foo/bar:

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
Judsen answered 28/8, 2019 at 11:7 Comment(4)
Do you mean that for most development the directories referred to inside ./build/conf/bblayers.conf are likely to be universal for all projects on a machine? So the paths refered to in bblayers.conf will be indepndant of the build directory as the build directroy will move the other things never will? – Reviewer
What I mean is that when you create a project, you do not know where people will instantiate the build directory, so using relative paths cannot work unless you make an assumption about the location of "build", which will then break if people call "source oe-init-build-env" from some other path (the "build" directory gets created as a subdirectory of the current directory when you call this script, so this can be anywhere on your filesystem). – Yeld
@Reviewer is something missing in my answer? why not accept it? – Yeld
The need to source the contents of the directory from anywhere on the filesystem could be the reason. It was not that clear in your first response but it is clearer now. – Reviewer
G
14

I found a way to use relative paths.

You can use inline python to traverse the file system. The following script uses the provided TOPDIR variable and then navigates to its parent via python's 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

Gigi answered 24/1, 2017 at 18:0 Comment(3)
How does YOCTOROOT differ from BBPATH or TOPDIR? I guess it gives you the effective ../ operation which would solve the issue and allow you to do ${YOCTOROOT}/my-layer/. – Reviewer
mentioned solution is more flexible the one being initially proposed by poky/oe-init-build-env script looking for ##OEROOT## and replacing with the current path. because if the complete recipies tree will be moved another place, conf file will not be update with a new path automatically as here. – Reina
Is it possible to use the new path syntax (from Python 3.4) in inline Python? Is it then possible to enter multiple Python commands? https://mcmap.net/q/13583/-how-do-i-get-the-parent-directory-in-python – Sassoon
M
10

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

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

with

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

I guess one caveat with this approach is that I'm relying on the meta-XXX layer directories always being in the parent folder of TOPDIR. This seems to be the case with the default way of using yocto, but might not be so for more customized build setups.

Mutualize answered 20/4, 2017 at 0:3 Comment(2)
Sounds like you managed to get the thing I probably failed to do to work. Maybe the tools have updated to allow this behaviour now. Thank you for your answer, but it does not address the question of why they were blocked. Although I suppose it demonstrates that now they may not be blocked any more so the answer could be that it was an mistaken without a reason. – Reviewer
I know this is an old ticket but have you tried ${BSPDIR} – Hallie
K
3

You can use relative paths in bblayers.conf.

There is probably this line in your bblayers.conf:

BBPATH = "${TOPDIR}"

When you want to find out this variable's content, you will probably find the top-level directory of your build directory:

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

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

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

So the answer on your question why there are absolute paths in bblayers.conf is that you can place your build directory anywhere on the system and not dependant from Yocto.

Relative Paths to Layers must always be relative to the build directory.

Kazachok answered 11/8, 2016 at 9:3 Comment(3)
Your answer seems to state that paths relative to a build directory are possible. Nothing says that relative paths can actually be used. If the Yocto (or bitbake) system takes only an Absolute path for ${TOPDIR} and then uses string manipulation to append the BBLAYERS paths, that is still using only absolute paths. Are you saying that the ability to put a build directory anywhere is maintained by the requirement of an absolute path to it? Is there a source for these statements. – Reviewer
I don't understand this. A relative path always needs a reference point. This sticks in the term "relative". In this point it would be BBPATH. You can access any file on your filesystem via a relative path provided that the security settings fit. – Kazachok
If I enter ./ or ../../ in the paths I use they fail. It is that sort of relative path that I am asking about. I can see that using the bitbake system it is possible to have some times in paths relative to other things within the bitbake ecosystem. I am asking why I cannot have a path defined as ../foo/bar.txt inside the bblayers.conf file when it seems possible in most of the other files I try it in. – Reviewer
J
3

All the existing answers are answering "how to use relative paths" but the question is "why are absolute paths used". As far as I know the "why" is simple, it is done that way so that the build directory can be moved anywhere on the filesystem. Think about it: you can source poky/oe-init-build-env from anywhere on the filesystem and the build directory will be created there, so relying on paths relative to the build directory is very fragile.

Edit:

maybe this is clearer, I think you are assuming that the file bblayers.conf is always in poky/build/conf/bblayers.conf and that you can therefore use a path like ../../meta-layer-foo to refer so some layer which would be in poky/meta-layer-foo, but the layer will not be found if I instantiate "build" in another path poky/foo/bar:

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
Judsen answered 28/8, 2019 at 11:7 Comment(4)
Do you mean that for most development the directories referred to inside ./build/conf/bblayers.conf are likely to be universal for all projects on a machine? So the paths refered to in bblayers.conf will be indepndant of the build directory as the build directroy will move the other things never will? – Reviewer
What I mean is that when you create a project, you do not know where people will instantiate the build directory, so using relative paths cannot work unless you make an assumption about the location of "build", which will then break if people call "source oe-init-build-env" from some other path (the "build" directory gets created as a subdirectory of the current directory when you call this script, so this can be anywhere on your filesystem). – Yeld
@Reviewer is something missing in my answer? why not accept it? – Yeld
The need to source the contents of the directory from anywhere on the filesystem could be the reason. It was not that clear in your first response but it is clearer now. – Reviewer
T
2

I am working with Rocko version and my bblayers.conf file also doesn't support relative paths I tried to change the bblayers.conf file by using TEMPLATECONF variable. TEMPLATECONF variable points to the directory containing bblayers.conf.sample, layer.conf, and local.conf.sample. I exported the TEMPLATECONF variable to get the desired bblayers.conf and local.conf files in the build directory but in my bblayers.conf.sample the BBLAYERS variable was set by a relative path 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 it doesn't seem to work.OEROOT variable was not able to set the correct paths. One reason could be that as oe-init-build-env script ends it unset the OEROOT variable. Although if you manually export OEROOT variable to your required value it may help. However, when I changed from OEROOT to TOPDIR variable it worked like a charm 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 make me think that unsetting of OEROOT variable by the oe-root-init-env script caused the problem. Also if somebody finds a better solution please respond.

Tertias answered 23/8, 2018 at 12:58 Comment(1)
You can use ##OEROOT## provided you use it in bblayers.conf.sample and you update your templateconf.cfg to point to your conf directory. I've added a separate answer to provide details about this strategy. – Drat
D
0

As you already mentioned in your self-comment, bblayers.conf is

intended to be specific to a user on a machine and only temporary.

IMHO, the idea is that bblayers.conf should never be distributed amongst developers. Nevertheless, if the absolute path of layers is something specific to each developers' system installation, it seems sound to keep the actual layer list as part of the project.

Inspired by Kamal Pandey's answer, I came up with a solution leveraging template file engine behind the oe-init-build-env script.

By changing the content of conf/templateconf.cfg to conf (instead of meta-poky/conf by default), you instruct oe-init-build-env to add any missing files in your configuration directory from its .sample counterpart (now located in your conf directory).

This way, renaming your bblayers.conf to bblayers.conf.sample lets you use the OEROOT variable (which is unfortunately no longer available after oe-init-build-env invocation).

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf                                                                                                                                      
# changes incompatibly                                                                                                                                                                                            
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \                                                                                                                                                                                                   
  ##OEROOT##/meta \                                                                                                                                                                                               
  ##OEROOT##/meta-poky \                                                                                                                                                                                          
  ##OEROOT##/meta-yocto-bsp \                                                                                                                                                                                     
  ${TOPDIR}/meta-tensorflow-lite \                                                                                                                                                                                
  "

With this bblayers.conf.sample file, you can now use the ##OEROOT## substitution variable to refer to file relative to your poky installation directory. By removing bblayers.conf (or not versioning/ditributing it), you ensure that sourcing oe-init-build-env will regenerate bblayers.conf with correct absolute values.

Drat answered 30/11, 2021 at 11:25 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.