Overriding the Variable in Distro.Conf Config File in Custom Image Recipe Yocto

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:

  1. Add the desired keyword in local.conf (or your MACHINE, or DISTRO, or whatever configuration)

  2. 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 set FILES_${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



Leave a reply



Submit