* Bitbake / oe-core anomaly with multilibs
@ 2013-03-18 19:12 Mark Hatle
2013-03-19 11:35 ` Richard Purdie
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hatle @ 2013-03-18 19:12 UTC (permalink / raw)
To: bitbake-devel
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"?
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?
Thanks for any insight!
--Mark
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Bitbake / oe-core anomaly with multilibs 2013-03-18 19:12 Bitbake / oe-core anomaly with multilibs Mark Hatle @ 2013-03-19 11:35 ` Richard Purdie 2013-03-19 12:44 ` Mark Hatle 0 siblings, 1 reply; 5+ messages in thread From: Richard Purdie @ 2013-03-19 11:35 UTC (permalink / raw) To: Mark Hatle; +Cc: bitbake-devel 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. Cheers, Richard ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bitbake / oe-core anomaly with multilibs 2013-03-19 11:35 ` Richard Purdie @ 2013-03-19 12:44 ` Mark Hatle 2013-03-19 13:30 ` Richard Purdie 0 siblings, 1 reply; 5+ messages in thread From: Mark Hatle @ 2013-03-19 12:44 UTC (permalink / raw) To: Richard Purdie; +Cc: bitbake-devel 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bitbake / oe-core anomaly with multilibs 2013-03-19 12:44 ` Mark Hatle @ 2013-03-19 13:30 ` Richard Purdie 2013-03-19 16:52 ` Chris Larson 0 siblings, 1 reply; 5+ messages in thread From: Richard Purdie @ 2013-03-19 13:30 UTC (permalink / raw) To: Mark Hatle; +Cc: bitbake-devel On Tue, 2013-03-19 at 07:44 -0500, Mark Hatle wrote: > 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". We could probably have data.expandKeys() check for existing values and then error if its overwriting something else. I have no idea how often the metadata does that for "correct" reasons... Cheers, Richard ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bitbake / oe-core anomaly with multilibs 2013-03-19 13:30 ` Richard Purdie @ 2013-03-19 16:52 ` Chris Larson 0 siblings, 0 replies; 5+ messages in thread From: Chris Larson @ 2013-03-19 16:52 UTC (permalink / raw) To: Richard Purdie; +Cc: bitbake-devel [-- Attachment #1: Type: text/plain, Size: 3719 bytes --] On Tue, Mar 19, 2013 at 6:30 AM, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Tue, 2013-03-19 at 07:44 -0500, Mark Hatle wrote: > > 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". > > We could probably have data.expandKeys() check for existing values and > then error if its overwriting something else. I have no idea how often > the metadata does that for "correct" reasons... I expect if the metadata really wants that, it could use a RecipePreFinalise hook. -- Christopher Larson [-- Attachment #2: Type: text/html, Size: 5121 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-03-19 17:10 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-18 19:12 Bitbake / oe-core anomaly with multilibs Mark Hatle 2013-03-19 11:35 ` Richard Purdie 2013-03-19 12:44 ` Mark Hatle 2013-03-19 13:30 ` Richard Purdie 2013-03-19 16:52 ` Chris Larson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.