Bitbake also has functionality that allows you to build multiple targets at the same time, where each target uses a different configuration.
In order to accomplish this, you setup each of the configurations
you need to use in parallel by placing the configuration files in
your current build directory alongside the usual
local.conf
file.
Follow these guidelines to create an environment that supports multiple configurations:
Create Configuration Files: You need to create a single configuration file for each configuration for which you want to add support. These files would contain lines such as the following:
MACHINE = "A"
The files would contain any other variables that can be set and built in the same directory.
TMPDIR
to not conflict.
Furthermore, the configuration file must be located in the
current build directory in a directory named
multiconfig
under the build's
conf
directory where
local.conf
resides.
The reason for this restriction is because the
BBPATH
variable is not constructed
until the layers are parsed.
Consequently, using the configuration file as a
pre-configuration file is not possible unless it is
located in the current working directory.
Add the BitBake Multi-Config Variable to you Local Configuration File:
Use the
BBMULTICONFIG
variable in your conf/local.conf
configuration file to specify each separate configuration.
For example, the following line tells BitBake it should load
conf/multiconfig/configA.conf
,
conf/multiconfig/configB.conf
, and
conf/multiconfig/configC.conf
.
BBMULTICONFIG = "configA configB configC"
Launch BitBake: Use the following BitBake command form to launch the build:
$ bitbake [multiconfig:multiconfigname
:]target
[[[multiconfig:multiconfigname
:]target
] ... ]
Following is an example that supports building a minimal
image for configuration A alongside a standard
core-image-sato
, which takes its
configuration from local.conf
:
$ bitbake multiconfig:configA:core-image-minimal core-image-sato
Support for multiple configurations in this current release of the Yocto Project (Morty 2.2.1) has some known issues:
No inter-multi-configuration dependencies exist.
Shared State (sstate) optimizations do not exist.
Consequently, if the build uses the same object twice
in, for example, two different
TMPDIR
directories, the build
will either load from an existing sstate cache at the
start or build the object twice.