CODEWITHSUNDEEP
yoctobitbakerecipe
Heiko
Heiko

Reputation: 103

Use different Sourcefiles in .bbappend (Immediate variable expansion)

We are using Yocto and bulding two slightly different images. One is just the standard image "bitbake standard-image" and the other one is a debug-image "bitbake debug-image" where additional programs, etc will be deployed. In both recipes the variable IMAGE_TYPE (=standard/debug) will be set. This variable should be used to deploy different sshd_conf files to the image. To achieve this I edited the openssh_%.append file which originally looked like this:

FILESEXTRAPATHS_prepend := "${THISDIR}/openssh:"

SRC_URI += " \
        file://sshd_config \
"

and now looks like this :

python () {
    if d.getVar('IMAGE_TYPE') == 'debug':
        d.appendVar('FILESEXTRAPATHS_prepend', '${THISDIR}/debug:')
        d.appendVar('SRC_URI', ' \\ file://sshd_config \\ ')


    if d.getVar('IMAGE_TYPE') == 'standard':
        d.appendVar('FILESEXTRAPATHS_prepend', '${THISDIR}/openssh:')
        d.appendVar('SRC_URI', ' \\ file://sshd_config \\ ')
}

My problem is that it does not work as intended. With the modification I did none of my sshd_config files gets deployed. Instead the default sshd_conf which comes with the layer is deployed. I think my problem is that the variable ${THISDIR} is not immediately expanded, but I don't know how to do that in "anonymous Python functions".

Does someone know how to make my changes work? Maybe this is not the way to go, is there a better way to deploy different files for different images ?

Thanks in advance Heiko

Upvotes: 2

Views: 1428

Answers (2)

ah008a
ah008a

Reputation: 1145

You're actually describing the purpose of DISTRO_FEATURES.

Fair warning that this wont work exactly as you thought of it initially because that's not how the system is designed to work, but it is possible to achieve.

Ok, first, Why doesn't your solution work?

It doesn't work because you are trying to achieve this at an IMAGE level, and bitbake does not allow the IMAGE "scope" to access/modify other recipes behaviour.

This means that setting a variable on image1.bb (in your case standard-image.bb) wont have any effect on recipeA.bb (in your case openssh.bbappend) since neither recipeA.bb can access the variables of image1.bb nor image1.bb can access the variables of recipeA.bb, this is by design.

Hence for your scenario, when you're trying to read the IMAGE_TYPE variable inside the openssh.bbappend via anonymous python:

if d.getVar('IMAGE_TYPE') == 'debug':

Nothing happens because for all openssh.bb knows, that variable isn't even set.

Here's where DISTRO comes into play, you CAN modify the behaviour of different recipes depending on which DISTRO you are building, that's precisely the reason DISTRO_FEATURES exist.

You can find several examples in the existing codebase, lets look at wpa_supplicant for a simple one:

if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
        install -d ${D}/${systemd_system_unitdir}
        install -m 644 ${S}/wpa_supplicant/systemd/*.service ${D}/${systemd_system_unitdir}
fi

if systemd is part of the DISTRO_FEATURES for the DISTRO being built, then bitbake will install additional files (systemd services in this case) for this package

Hence, if you add systemd to your DISTRO_FEATURES in your DISTRO.conf by something like:

DISTRO_FEATURES:append = " systemd"

You'll get those files in your image (regardless of which image you are building), if systemd is not there those files wont be there on the resulting image either.

You can do the something similar an add a "my-debug-feature" to your distros:

DISTRO_FEATURE:append = " my-debug-feature"

and then on the recipe essentially do the same check as above:

if ${@bb.utils.contains('DISTRO_FEATURES','my-debug-feature','true','false',d)}; then
        install -m 644 ${S}/sshd_standard_config ${D}/${sysconfdir}/sshd_config
else
        install -m 644 ${S}/sshd_debug_config ${D}/${sysconfdir}/sshd_config
fi

There are several other examples you can find bluez, connman, inetutils, which modify installation or modify recipe's behavior in some way if a certain DISTRO_FEATURE is present.

Now, I know you thought of this by using two images and you may find this answer frustrating, so, you can certainly have two images and not two DISTROs but it needs to be architected in a different way (The recommended way is still using DISTRO_FEATURES though since its cleaner on the long run).

If you reaaally want to use images instead of separate DISTROs, what you can do is instead of trying to react based on a variable (IMAGE_TYPE), simply place the extra files on a different package, e.g. openssh-standard-config vs openssh-debug-config (These can be separate recipes for simplicity so you dont have to deal as much with conflicts) and on each image install the package that belongs to it.

standard-image.bb:

IMAGE_INSTALL:append = " openssh-standard-config"

debug-image.bb

IMAGE_INSTALL:append = " openssh-debug-config"

You may be tempted to look at IMAGE_FEATURES, but you'll soon realize that it wont allow you to achieve what you want either for the same reason as above

Upvotes: 0

schlimmchen
schlimmchen

Reputation: 229

You probably should use d.prependVar("FILESEXTRAPATHS", ...) not d.appendVar("FILESEXTRAPATHS_prepend", ...).

We tried your approach as well (in Python), and for us it failed since ${THISDIR} was not expanded to the directory in which the .bbappend file was stored, but the parent directory of the original .bb file. Maybe that is (or was) a bitbake bug?

How about a subdirectory per image type with the respective name (no Python block needed):

FILESEXTRAPATHS_prepend := "${THISDIR}/files_${IMAGE_TYPE}:"

This does not exactly what you want (subdirectory name is not the same as the image type), but it works well.

Upvotes: 0

Related Questions