====== multiconfig ======

[[https://docs.yoctoproject.org/next/dev-manual/multiconfig.html#building-images-for-multiple-targets-with-multiconfig|13 Building Images for Multiple Targets With Multiconfig]]

With default - no multiconfig - usage bitbake works with one config ''local.conf''.
It is possible to use bitbake parallel tasks to build more targets and machines at the same time.
When bitbake target is prefixed with special ''mc:configname:target'' then bitbake looks for ''configname.conf'' instead of ''local.conf''.
Default ''local.conf'' is still avail as empty config ''mc::target''.

Bitbake looks for additional configs in ''multiconfig'' directory. 
This directory can be located in 2 places:
  * in build ''conf'' directory
    * ''conf/local.conf''
    * ''conf/multiconfig/configname1.conf
    * ''conf/multiconfig/configname2.conf
  * in layer ''conf'' directory:
    * ''meta-custom/conf/multiconfig/confignameX.conf''

Pros:
  * Acts as predefined ''local.conf'' shipped within layer.
  * It has great benefits when SSTATE cache is already filled and when multiple rootfs images are assembled in parallel.
  * The same TMPDIR can be used, when building the same distro for multiple similar machines and multiple similar images.
  * [[https://docs.yoctoproject.org/next/dev-manual/multiconfig.html#common-use-case-building-baremetal-firmware-alongside-a-linux-build|13.4 Common use case: building baremetal firmware alongside a Linux build]]

Cons:
  * With empty SSTATE it can perform even worse than sequential build where 1st build will store some reusable object in sstate cache.
    * See <code>
Note
Support for multiple configuration builds in the Yocto Project 5.3.999 (Whinlatter) Release does not 
include Shared State (sstate) optimizations. Consequently, if a build uses the same object twice in, for example,
two different TMPDIR directories, the build either loads from an existing sstate cache for that build at the
start or builds the object fresh.
</code>
  * Separate TMPDIR must be used when crucial configs are changed between multiconfis. Common practice is to use separate TMPDIR per distro.


Example usage:

invoke bitbake target with prefix:
<code shell>
bitbake mc:configname:target1 mc:configname:target2
</code>
the default config - ''local.conf'' is still available - as unnamed config:
<code shell>
bitbake mc::target1
</code>

<file yaml myconfig.yml>
---
header:
  version: 18

target:
  - mc:genio-510-sbc:core-image-minimal
  - mc:genio-700-sbc:core-image-minimal
  - mc:genio-700-evb:core-image-minimal
...
</file>


===== TMPDIR =====

<file conf myconfig.conf>
DISTRO = "poky"

# rename TMPDIR with option to override it:
MY_TMP_APPEND ?= "-poky"
TMPDIR:append = "${MY_TMP_APPEND}"
</file>

or

<file conf local.conf>
TMPDIR = "${TOPDIR}/tmp-${DISTRO}"
</file>

[[https://lists.yoctoproject.org/g/meta-ti/topic/patch_multiconfig_use/91431962|[PATCH] multiconfig: use diferent TMPDIR for each machine]]

[[https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/conf/multiconfig/k3r5.conf?h=scarthgap|path: root/meta-ti-bsp/conf/multiconfig/k3r5.conf]]

===== references =====


“Multiconfig Inception” by Joshua Watt:
  * [[https://www.youtube.com/watch?v=YvtlGjWrL-M]]
  * [[https://github.com/JPEWdev/meta-multiconfig-demos|meta-multiconfig-demos]]

Use BB multiconfig with kas:
  * [[https://github.com/siemens/kas/issues/30|Multi-config support needs to be documented #30]]
  * [[https://github.com/siemens/jailhouse-images|Jailhouse Reference Images]]