Introducing EXOTIC defines

^{Home / parallella-yoctobuild / meta-exotic / Design Guide / Introduction / Introducing EXOTIC defines}

^{Basic Poky SDK Idea Interesting defaults}

In the meta-exotic layer there are four key defines that characterise the system. Take the SYS variable as an example. In traditional Yocto there are three types of SYS: BUILD_SYS the system of the build machine (for example BUILD_SYS="x86_64-linux"); HOST_SYS the system on which the executable will be run (for example HOST_SYS=arm-poky-linux-gnueabi); TARGET_SYS the system that the compiler output will be created for (for example TARGET_SYS=arm-poky-linux-gnueabi). These three defines enable a compiler to be built that will run on the arm processor and produce code for the arm processor.

The meta-exotic layer adds a fourth define EXOTIC_TARGET_SYS that enables a compiler to be built that will run on the arm processor and produce code for a microcontroller or other exotic CPU. In addition it replaces TARGET_SYS with TARGET_SYS_GVARIABLE so that TARGET_SYS may be used outside the meta-exotic layer with whatever value is appropriate to get the desired result.

The best way to understand the ?_GVARIABLE and EXOTIC_? variables is by example. Take the example of epiphany-elf-gcc-cross-canadian (built with --host=x86_64-pokysdk-linux --target=epiphany-elf). This will produce a compiler that will run in the Poky SDK environment and produce code for the Epiphany CPU. This code can be copied directly to the arm based system from the Poky SDK and run on the Epiphany CPU

The Yocto python code parses the various file in a particular sequence and at several points this process the TARGET_SYS variable is set.

1 First in bitbake.conf:

TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + d.getVar('TARGET_OS', True), ''][d.getVar('TARGET_OS', True) == ('' or 'custom')]}"

2 And in meta-exotic/conf/site.conf:

TARGET_SYS_GVARIABLE = ""
EXOTIC_TARGET_SYS = ""

3 Then in epiphany-elf-gcc-cross-canadian_4.8.bb:

EXOTIC_TARGET_SYS = "epiphany-elf"

4 Then in meta-exotic/classes/autotools_exotic.bbclass:

TARGET_SYS_GVARIABLE := "${TARGET_SYS}"
TARGET_SYS = "${EXOTIC_TARGET_SYS}"

Looking in the bitbake -e output for this build we see:

#   set in poky/meta/conf/bitbake.conf:123
#     "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + d.getVar('TARGET_OS', True), ''][d.getVar('TARGET_OS', True) == ('' or 'custom')]}"
#   set in meta-exotic/classes/autotools_exotic.bbclass:46
#     "${EXOTIC_TARGET_SYS}"
#   override[GVARIABLE]:set meta-exotic/conf/site.conf:28
#     ""
#   override[GVARIABLE]:immediate meta-exotic/classes/autotools_exotic.bbclass:34
#     "${TARGET_SYS}"
# pre-expansion value:
#   "${EXOTIC_TARGET_SYS}"
TARGET_SYS="epiphany-elf"

####Description of the above flow:

Perhaps you are new to Yocto.. if so well done for reading to this point. If you want a quick overview of the variables and the syntax have a quick look at the links on the Basic syntax page. If not read on for a brief description of the above steps.

Step 1. generates "arm-poky-linux-gnueabi" from TARGET_ARCH, TARGET_VENDOR and TARGET_OS, but only when the variables are expanded.

Step 2. ensures that if there are no bb files that use the EXOTIC_TARGET_SYS variable that a suitable default value is used. Step 3 overwrites this with "epiphany-elf" and as no further changes are made this is what EXOTIC_TARGET_SYS will have when bitbake takes any action with this variable.

Step 4 is more complex and contains the key to how the whole thing works. First TARGET_SYS_GVARIABLE is immediately assigned (:=) to whatever TARGET_SYS has at the time that the python code parses the file. When the python code parses the := assignment statement it immediately processes the right hand side and generates the resulting string (see Bitbake Basic Syntax. In this example:

# $TARGET_SYS_GVARIABLE [2 operations]
#   set in meta-exotic/conf/site.conf:28
#     ""
#   immediate meta-exotic/classes/autotools_exotic.bbclass:34
#     "${TARGET_SYS}"
# pre-expansion value:
#   "arm-poky-linux-gnueabi"
TARGET_SYS_GVARIABLE="arm-poky-linux-gnueabi"

So the ?_GVARIABLES are used to take an immediate snapshot of the value of the variables effectively at the start of the bb file processing. This value can be used later in the scripts if necessary.

The second part of Step 4 replaces TARGET_SYS with the value that is needed to ensure that the epiphany-elf-gcc-cross-canadian build is correctly configured with --target=epiphany-elf. Note that = is the assignment so the expansion of the right hand side is only done when the variable is used.

So the TARGET_SYS variable is free to be used to hold the actual target for the compile step and the TARGET_SYS_GVARIABLE holds the value original value of TARGET_SYS before the meta-exotic layer was parsed so that it is also available if necessary.

^{Basic Poky SDK Idea Interesting defaults}