[bitbake-devel] Regression caused by new multiconfig dependency

[Jan Kiszka]

On 20.11.18 19:23, Alejandro Enedino Hernandez Samaniego wrote:
> Hey Jan,
> 
> I literally just sent out a patch to fix this issue, it should work fine after 
> that is applied.
> 

Thanks a lot, your patch [1] is working fine for us as well.

Jan

[1] 
https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=aehs29/multiconfig_provides&id=c075cac18c32f4b178fc4f62b4326118b43dc99f

> 
> Cheers,
> 
> Alejandro
> 
> 
> On 11/20/2018 12:48 AM, Jan Kiszka wrote:
>> 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
>