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.
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
OpenEmbedded's bitbake.conf
Advanced functionality with python
How do I get the parent directory in Python?
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.
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
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.
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.
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.
Related
As you know, Buildroot allow save current configuration without default value. It is good idea for me because full configuration is too large to be read by human.
But
make savedefconfig
doesn't save
BR2_EXTERNAL_XYZZY_PATH's path. Is it a bug?
--How to reproduce?--
mkdir BuildRootTest && cd BuildRootTest
aria2c https://bugs.busybox.net/attachment.cgi?id=9461 --out '.7z'
7z x .7z
rm .7z
git clone https://github.com/buildroot/buildroot
make BR2_EXTERNAL=${PWD}/my_external_tree -C
buildroot pc_x86_bios_defconfig
make -C buildroot savedefconfig BR2_DEFCONFIG=${PWD}/'mydefconfig01'
Compare mydefconfig01 and buildroot/.config files. mydefconfig01 contains "BR2_EXTERNAL_USERCONFIGTREE_PATH" ones but buildroot/.config twice. make savedefconfig just remove BR2_EXTERNAL_USERCONFIGTREE_PATH="/home/username/delme/my_external_tree" from mydefconfig01.
I wanted to mock some of my files, so I used Cuckoo framework. I am using Swift Package Manager, so I did every step that is shown in README of framework.
I tried to use this script
# Define output file. Change "${PROJECT_DIR}/${PROJECT_NAME}Tests" to your test's
root source folder, if it's not the default name.
OUTPUT_FILE="${PROJECT_DIR}/${PROJECT_NAME}Tests/GeneratedMocks.swift"
echo "Generated Mocks File = ${OUTPUT_FILE}"
# Define input directory. Change "${PROJECT_DIR}/${PROJECT_NAME}" to your project's root source folder, if it's not the default name.
INPUT_DIR="${PROJECT_DIR}/${PROJECT_NAME}"
echo "Mocks Input Directory = ${INPUT_DIR}"
# Generate mock files, include as many input files as you'd like to create mocks for.
"${PROJECT_DIR}/run" --download generate --testable "${PROJECT_NAME}" \
--output "${OUTPUT_FILE}" \
"${INPUT_DIR}/Common/Repository/LatestNewsRepository/LatestNewsRepositoryImpl.swift" \
# ... and so forth, the last line should never end with a backslash
# After running once, locate `GeneratedMocks.swift` and drag it into your Xcode test target group.
I also downloaded the latest run script and I had to check For install builds only.
When app is launched I am getting this error -
Stale file '.../LibraryTests/GeneratedMocks.swift' is located outside of the allowed root paths.
Things I tried -
Clean Xcode derived data
Clean build folder
Reset Xcode
Reset Packages Cache
and I am still not getting output file. Is there anything else I should try?
Changing the path of a Yocto environment is not a good idea, as I found out. This also explains why e.g. bitbake can be run regardless the current working directory. Absolute paths are stored in many places during the build process, even subdirectory structures are created into the tmp directory tree. I ended up in rebuilding from scratch - which takes a long time.
A documentation of how I tried to modify all paths:
find . -name *.conf -exec sed -i 's/media\/rob\/3210bcd4-49ef-473e-97a6-e4b7a2c1973e/home/g' {} +
This step replaces absolute paths, within many dynamic conf files (from xx/xx/linux to /home/linux - where linux was chosen for historical reasons. I could mount the partition also as /home/yocto or whatever name).
Next was deletion of subdirectory structures with the old path in the hope that the build process would recognize these deletions, and still rebuild quickly:
find . -name *3210bcd4-49ef-473e-97a6-e4b7a2c1973e* -exec fakeroot rm -r {} +
It was not recognized. Then I gave up.
From a user new to Yocto, familiar with former/classic crossbuild environments based on make menuconfig etc.
My question is:
Why are absolute paths generated & used throughout tmp instead of treating everything as relative?
Or, asked differently:
Why not use something like ${TOPDIR}/tmp throughout the build configuration, instead of hardcoding the absolute path to tmp?
I was trying to create a new syslog-startup.conf by creating a busy-box%.bbappend having the following in it:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "\
file://syslog-startup.conf \
"
do_install_append() {
install -m 0644 ${WORKDIR}/syslog-startup.conf ${D}${sysconfdir}/syslog-startup.conf
}
FILE_${PN} += "\
${sysconfdir}/syslog-startup.conf \
"
My syslog-startup.conf is the same as the default one except i have it logging to a file instead of a buffer on system startup instead of my having to go in and change it manually. I never have this work. I always have the default .conf file installed on system startup. I should mention that I'm also having the same issue when i try to update another of my system files: /etc/fstab which also doesn't work and i end up with default file installed.
Why am I not able to change/append to system files?
Is there a better way to do this?
Is there a way to find out if my .bbappend file got executed at all?
I had to alter the syslog-startup.conf for a different reason. How I managed to do it was by adding the below line in my busybox_%.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
I added the modified syslog-startup.conf inside a folder called files. Where you place the file is upto you. Yocto will replace the default file with the file provided by the .bbapend file. So all you will have to do is point to the file in your busybox_%.bbapend file
I have problems setting "run configuration" in Eclipse. When I use the Windows cmd to compile and run java.class I use .bat file that looks like this:
rem Wipe standard Windows Path variable and use this:
set PATH = C: \ Program Files \ .this path.;..and this one..;…;…
rem needed CLASSPATH's
set CLASSPATH = "... some \ path / *; ...
rem Path to native .dll libs
set LIB_PATH = "C: \ ... \ bin"
javac-cp% CLASSPATH% "... \ SomeExample.java"
java-cp% CLASSPATH%-Djava.library.path =% LIB_PATH% SomeExample
And everything works as it should, both compile and run are ok. When I try to do the same through Eclipse, by adjusting the classpath in run configuration GUI, compile is ok (I test it manualy in CMD), but during execution compiled class, I get java.lang. "UnsatisfiedLinkError ... someImportantDLL.dll: The specified procedure could not be found, " Which is the same error that I get while running in cmd if I do not set the PATH enviroment variable manually in .bat file!
What should I do in Eclipse to run properly compiled class?
Add the correct -Djava.library.path to the VM Arguments field. Don't rely on the external environment--you should control everything about your application's environment so you won't have any "gotchas" when you roll it out.