[bitbake-devel] Regression caused by new multiconfig dependency

[Jan Kiszka]

On 18.11.18 10:59, Jan Kiszka wrote:
> Hi all,
> 
> since da8cb8633504 ("bitbake: Add support for multiconfig dependencies"), it's 
> no longer possible to write recipes that have multiconfig-dependent names:
> 
> 
> mc1.conf:
> MACHINE = "a"
> 
> mc2.conf:
> MACHINE = "b"
> 
> some-target.bb:
> PN = "some-target-${MACHINE}"
> 
> local.conf:
> BBMULTICONFIG = "mc1 mc2"
> 
> 
> # bitbake multiconfig:mc1:some-target-a
> [...]
> ERROR: Nothing PROVIDES 'some-target-a'. Close matches:
>    some-target-b
> 
> # bitbake multiconfig:mc2:some-target-b
> ERROR: Nothing PROVIDES 'some-target-b'. Close matches:
>    some-target-a
> 
> 
> That works fine when going back to da8cb8633504^ or when only having the 
> selected multiconfig in BBMULTICONFIG. Seems the parser stumbles while 
> processing the unselected multiconfig paths.
> 
> Jan

Including also the author of that commit.

I'm not really understanding the internals of bitbake yet, I just started to track down the issue to a code change:

def buildTaskData(...):
    ...
            if mc:
                # Provider might be from another mc
                for mcavailable in self.multiconfigs:
                    # The first element is empty
                    if mcavailable:
                        taskdata[mcavailable].add_provider(localdata[mcavailable], self.recipecaches[mcavailable], k)

If we do multiconfig:mc1:some-target-a, add_provider() still works fine for mcavailable = "mc1", but it fails with the error above for "mc2", apparently because "some-target-a" cannot be resolved in mc2. Any idea how that can be avoided? I don't get why we should check for the build target when adding the mc with all its targets as providers.

Thanks,
Jan