Override variable from other recipe that is not soft assigned (?=)
If you have a distro configuration you could use overrides, something like:
FOO_<distro_override> = "valueB"
to reset the variable when your distro is configured. In a .bbappend, a second assignment parsed after the first would override the original value so:
FOO = "value2"
would work too as it would reset the original value due to be parsed later.
How to override DISTRO_VERSION?
To change SDK version, you need to use SDK_VERSION variable defined in poky
as:
SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
Adding DISTRO_FEATURES to image bitbake recipe
Correct, you can't set DISTRO_FEATURES in a recipe. It controls the features of the distro, so only makes sense in a distro configuration or other top-level configuration file such as local.conf.
Yocto: Install different config files based on MACHINE type or target image
do_install_append () {
// install common things here
}
do_install_append_machine-1 () {
// install machine-1 specific things here
}
do_install_append_machine-2 () {
// install machine-2 specific things here
}
The value of MACHINE is automatically added to OVERRIDES, which can be used at the end of a function append to have a MACHINE-specific addition to a function.
Maybe useful: https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-OVERRIDES
using require in layer.conf in yocto
Even if it seems to work, neither of your approaches is technically completely correct. The key point is that all .conf
files are parsed first and everything they contain is globally visible throughout the whole build process. So if you add something through the layer.conf
file, itis not being pulled in through an unexpected place, it also is not being limited that layer only and might therefore cause breakage at other places.
While I do not have a really good and clean solution, maybe the following can help you:
You can make your custom recipes react on certain keywords in DISTRO_FEATURES
or MACHINE_FEATURES
. Then you can create a two-staged approach:
Add the desired keyword in
local.conf
(or yourMACHINE
, orDISTRO
, or whatever configuration)Make the recipes react to it. If you need the mechanism in several places, then it might be useful to pour it into a
.bbclass
that your layer brings along and that you pull in for the respective recipes.
This way the effect is properly contained.
How to give options for configure using yocto recipes?
You can provide the configure options using EXTRA_OECONF. Here, you can also append values to it based on your architecture.
EXTRA_OECONF_append_x86="--enable-x86"
EXTRA_OECONF_append_x64="--enable-x64"
You can do this only if your architecture (x86/x64) is defined as aprt of OVERRIDE value. Let us see what OVERRIDE value is:
The Yocto bitbake configuration values are defined in poky/meta/conf/bitbake.conf. In that file, there is a variable called OVERRIDE. The sample value for OVERRIDE in bitbake configuration is shown below:
OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable"
When you run bitbake -e and gather the output, the value for OVERRIDE translates into based on your configuration.
OVERRIDES="linux:i586:build-linux:pn-defaultpkgname:x86:qemuall:qemux86:poky:class-target:forcevariable:libc-glibc"
In your setup, if you can see x86/x64 as part of OVERRIDE value then you can define configure options as described earlier.
Yocto Bitbake Recipe How To Override do_install() and do_install_append()
do_install () {
install -d ${D}${base_bindir}
mv ${D}/../build/pgrep ${D}/bin/pgrep
}
do_install_append () {
install -d ${D}${base_bindir}
mv ${D}/../build/pgrep ${D}/bin/pgrep
}
There's a few bits of confusion here:
- You can't "override" another _append: the one in the original recipe will still be appended
- Even if you could, your version would try to mv the same file twice (in the install and the append): that would fail. mv in general is a bad idea here: use
install
that's what it's for. - Using
${D}/../build/
is not right, you probably want${B}
instead -- but that should also be the default directory for do_install() so you shouldn't need it at all.
You could let the original do_install() do what it wants, and then remove the bits you don't want in do_install_append()... but I think modifying the package so much is not a great idea: what if another package runtime depends on procps and expects the tools you removed?
Some alternatives for you:
- copy the recipe under a new name and just modify it
- Let do_install be as is and in your bbappend add a new package
PACKAGES =+ ${PN}-pgrep
and setFILES_${PN}-pgrep = "${bindir}/pgrep"
: then you could install only the new tiny procps-pgrep package instead of procps. This might need some tweaking to get right because of the alternatives system procps uses...
Related Topics
How to Run Multiple Programs in a Sequence
Bash -C Variable Does Not Get Assigned
Script Produces Different Result When Executed by Bash Than by Cron
How to Find Files with Same Size
Update Specific Field in Text File in Specific Line
How to Route Webcam Video to Virtual Video Device on Linux (Via Opencv)
How to Add Text After Last Pattern Match Using Ed
Allocating a Data Page in Linux with Nx Bit Turned Off
Script to Get User That Has Process with Most Memory Usage
How to Create a Bash Variable Like $Random
How to Merge Two Rows in a Same Row from a Text File in Linux Shell Script
A Way to Prevent Bash from Parsing Command Line W/Out Using Escape Symbols
When Installing Rust Toolchain in Docker, Bash 'Source' Command Doesn't Work
How to Start/Restart/Stop Apache Server on Linux as Non-Root User
Linux Command Ambiguous Redirect
Print the Output of Strace Command in a Text File
Compling C++ Code Using Command Line
Terminate an Ongoing Qprocess That Is Running Inside a Qthread