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:

• It has great benefits when SSTATE cache is already filled and when multiple rootfs images are assembled in parallel.

Cons:

• With empty SSTATE it can perform even worse than sequential build where 1st build will store some reusable object in sstate cache.

Example usage:

invoke bitbake target with prefix:

bitbake mc:configname:target1 mc:configname:target2

the default config - local.conf is still available - as unnamed config:

bitbake mc::target1

“Multiconfig Inception” by Joshua Watt:

• https://www.youtube.com/watch?v=YvtlGjWrL-M
• meta-multiconfig-demos

Use BB multiconfig with kas:

• Multi-config support needs to be documented #30
• Jailhouse Reference Images