We will sometimes add customizations that are specific to one board or machine. These are not always hardware-related, so they could be found both in a BSP or software layer.

When doing so, we will try to keep our customizations as specific as possible. One typical example is customizing for a specific machine or machine family. If you need to add a patch for the wandboard machine, you would use the following line of code:

SRC_URI_append_wandboard = " file://mypatch.patch" 

And, if the patch is applicable to all i.MX6-based boards, you can use the following:

SRC_URI_append_mx6 = " file://mypatch.patch" 

To be able to use machine family overrides, the machine configuration files need to include a MACHINEOVERRIDES variable, such as the one for the wandboard in the meta-freescale-3rdparty layer machine configuration file, as show here:

conf/machine/wandboard.conf:MACHINEOVERRIDES =. "mx6:mx6dl:mx6q:" 

This is included as part of the default OVERRIDES variable as defined in meta/conf/bitbake.conf in the poky layer:

OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable" 

The override mechanism allows us to conditionally set variables as follows:

VARIABLE_override1_override2 = "" 

Or we can use the _append, _prepend, and _remove syntax:

VARIABLE_append_override1_override2 = "" 
VARIABLE_prepend_override1_override2 = "" 
VARIABLE_remove_override1_override2 = "" 

BitBake will search a predefined path, looking for files inside the package's working directory, defined in the FILESPATH variable as a colon-separated list. Specifically:

${BPN}-${PV}/${DISTRO} 
${BPN}/${DISTRO} 
files/${DISTRO} 
 
${BPN}-${PV}/${MACHINE} 
${BPN}/${MACHINE} 
files/${MACHINE} 
 
${BPN}-${PV}/${MACHINEOVERRIDES} 
${BPN}/${MACHINEOVERRIDES} 
files/${MACHINEOVERRIDES} 
 
${BPN}-${PV}/${TARGET_ARCH} 
${BPN}/${TARGET_ARCH} 
files/${TARGET_ARCH} 
 
${BPN}-${PV}/ 
${BPN}/ 
files/ 

In the specific case of the wandboard, this translates to the following:

${BPN}-${PV}/poky 
${BPN}/poky 
files/poky 
${BPN}-${PV}/wandboard 
${BPN}/wandboard 
files/wandboard 
${BPN}-${PV}/mx6q 
${BPN}/mx6q 
files/mx6q 
${BPN}-${PV}/mx6dl 
${BPN}/mx6dl 
files/mx6dl 
${BPN}-${PV}/mx6 
${BPN}/mx6 
files/mx6 
${BPN}-${PV}/armv7a 
${BPN}/armv7a 
files/armv7a 
${BPN}-${PV}/arm 
${BPN}/arm 
files/arm 
${BPN}-${PV}/ 
${BPN}/ 
files/ 

Here, BPN is the package name with prefixes and suffixes (such as nativesdk-, -native and others) removed, and PV is the package version.

It is best to place patches in the most specific of these, so wandboard, followed by mx6q or mx6dl, mx6, armv7a, arm, and finally the generic BPN-PV, BPN, and files directory.

Note that the search path refers to the location of the BitBake recipe, so append files need to always add the path when adding content. Our append files can add extra folders to this search path if needed by appending or prepending to the FILESEXTRAPATHS variable as follows:

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

Let's finish with a quick overview of the common BitBake syntax. The following assignments are evaluated first:

• = expand when used
• := expand when parsed
• ?= immediately expand when parsed if empty
• += immediately append when parsing with leading space
• .= immediately append when parsing without a space
• =+ immediately prepend when parsing with trailing space
• =. immediately prepend when parsing without a space

After BitBake evaluates the previous assignments, it will evaluate the _append and _prepend syntax. Finally, it will evaluate the ??= assignment, which is identical to ?= except for the parsing order.

With this explanation it is easier to understand that configuration files, which are parsed first by BitBake, make use of the _append and _prepend syntax so that the assignments are deferred and recipes and classes using weak symbols such as ?= have their defaults applied. If conf/local.conf, for example, used the =+ assignment, a recipe using ?= would not have the default applied.