Regression caused by new multiconfig dependency

Regression caused by new multiconfig dependency

[Jan Kiszka]

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

Re: 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

Re: 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
>