Bug 12985

Summary: multiconfig in v2.6 no longer works with COMPATIBLE_MACHINE (e.g. in image recipes)
Product: [Build System, Metadata & Runtime] BitBake Reporter: Christian Andersen <c.andersen>
Component: bitbakeAssignee: Alejandro Hernandez <alejandr>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: poky.bs.watcher, poky.watcher, randy.macleod
Version: 2.6   
Target Milestone: 2.7 M1   
Hardware: x86   
OS: Multiple   
Whiteboard: Backport to 2.6.1
OS type for building Yocto: --- Type of Regression: Regression (Used to work)
Verified: Documentation change: No (bug/feature does not impact docs)

Description Christian Andersen 2018-11-07 10:27:01 UTC 
We are using multiconfig to build multiple architectures (arm and qemux86) as well as a specific release configuration. We have an image recipe which only works for arm (not for qemux86), so we use COMPATIBLE_MACHINE in that recipe.

With pyro, sumo and rocko this worked without issues. After upgrading to the current version of thud, we are getting some errors.

I already tracked it down to the new mcdepends support in 2.6. If I revert the commits b7c2c785806e53351340fe27270784115ea172b0 and b8730f68d22b9c1ebd012ffd7aedccd22cceb0da our build works again.

Steps to reproduce:

- clone thud branch of poky
- initialize default build config (. oe-init-build-env)
- add the following lines to build/conf/local.conf:

  BBMULTICONFIG = "release x86"
  MACHINE ?= "beaglebone-yocto"
  COMPATIBLE_MACHINE_pn-core-image-minimal = "beaglebone-yocto"

- create empty build/conf/multiconfig/release.conf (in our case it is not empty, but that is enough to reproduce this issue)
- create build/conf/multiconfig/x86.conf:

  MACHINE = "qemux86"

- run bitbake and build core-image-minimal for the release multiconfig

  bitbake multiconfig:release:core-image-minimal

Error message:
ERROR: Nothing PROVIDES 'core-image-minimal'
core-image-minimal was skipped: incompatible with machine qemux86 (not in COMPATIBLE_MACHINE)

This error would be correct, if I try to build core-image-minimal for x86 multiconfig (qemux86 machine). But we try to build the release multiconfig (beaglebone machine) and the core-image-minimal is compatible with that.

Remark: To simplify things, I use the existing core-image-minimal and set COMPATIBLE_MACHINE for it. In our case it is another image which really is only compatible with the default machine.
Comment 1 Alejandro Hernandez 2018-11-09 00:08:43 UTC 
Ok, so whats happening is that the multiconfig name is getting split from the target to be built, and then we are checking for PROVIDERS for that target for all the available multiconfigs regardless if we actually need to build that target for that multiconfig or not.

The issue here is that the taskdata object is not aware of which multiconfig is building, hence why we split the multiconfig name before checking for PROVIDERS, but yes, we should only check for PROVIDERS either when we are building for that target or when we have a multiconfig dependency to it.