[bitbake-devel] Bitbake / oe-core anomaly with multilibs
Mark Hatle
mark.hatle at windriver.com
Tue Mar 19 12:44:05 UTC 2013
On 3/19/13 6:35 AM, Richard Purdie wrote:
> On Mon, 2013-03-18 at 14:12 -0500, Mark Hatle wrote:
>> I found a strange situation today and I'm looking for an explanation to see if
>> it's a bug or not.
>>
>> Between a .bb and .bbappend file, I end up with a situation where
>> "reproducer.bb" and "reproducer.bbappend" get the following:
>>
>> RDEPENDS_${PN} += "hello1"
>> RDEPENDS_reproducer += "hello2"
>>
>> When evaluatated (bitbake -e reproducer) I get:
>>
>> #
>> # $RDEPENDS_reproducer [2 operations]
>> # append
>> /home/mhatle/git/oss/oe-core/local/recipes-sample/hello/reproducer_1.0.bb:16
>> # "hello2"
>> # rename from RDEPENDS_${PN} data.py:161 [expandKeys]
>> # " hello1"
>> # computed:
>> # " hello1"
>> RDEPENDS_reproducer="hello1"
>>
>> So that tells me that it was initially set to "hello2", and then the ${PN}
>> expansion occurred, causing it to be set to "hello1".
>>
>> So my first question is, should this be "hello1", "hello2", "hello1 hello2" or
>> "hello2 hello1"?
>
> expandKeys tramples existing values so that result doesn't surprise me
> even if its not what you expect.
>
>> The second issue is a bit stranger.. if I change the build from "reproducer" to
>> "lib32-reproducer", I get a different result:
>>
>> # $RDEPENDS_lib32-reproducer [3 operations]
>> # rename from RDEPENDS_${PN} data.py:161 [expandKeys]
>> # " hello1"
>> # rename from RDEPENDS_reproducer classextend.py:95 [rename_package_variables]
>> # " hello2"
>> # set classextend.py:71 [map_depends_variable]
>> # "lib32-hello2"
>> # computed:
>> # "lib32-hello2"
>> RDEPENDS_lib32-reproducer="lib32-hello2"
>>
>> This time the system pulled in the ${PN} version first (obviously expanded it),
>> and then turned out and found the RDEPENDS_reproducer, and remapped it to
>> RDEPENDS_lib32-reproducer replacing the origin ${PN} version.
>>
>> So I have two concerns, the first is the value is 'different' from the
>> non-multilib version, and second, what should the expected output be for this item?
>
> Again, I'm not surprised. The multilib remapping code gets executed at
> the end, after expandKeys and in this case last wins. So I can see why
> the system is doing it, even if you don't like the end result.
>
> Setting multiple conflicting keys like this is dangerous :(
>
> We've tried to fix this before and ended up just digging deeper holes
> with more problems.
Is there any way we can issue a warning from the parser or something when it
finds conflicting keys? My concern isn't that conflicting keys are causing a
problem -- but more that someone may not realize this is a problem, and they are
getting incorrect results.
I know since posting this query, I've had a few people comment to me that they
saw the same problem and it took them a very long time to diagnose it and figure
out it "just didn't work".
--Mark
> Cheers,
>
> Richard
>
More information about the bitbake-devel
mailing list