Hi there,
following up on a discussion we had at [1]...
Currently most of the recipes in core and meta-openembeeded are written like
recipe-a_1.0.bb
---
SUMMARY = "Foo"
LICENSE = "Bar"
LIC_FILES_CHKSUM = "file://LICENSE;md5=a4a2bbea1db029f21b3a328c7a059172"
DEPENDS = "some-dependency"
---
if you now think of the following:
local.conf
---
INHERIT += "magic"
---
magic.bbclass
---
DEPENDS = "magic-dependency"
---
then `magic-dependency` doesn't end up in recipe-a's DEPENDS chain.
While when you alter the recipe to
recipe-a_1.0.bb
---
SUMMARY = "Foo"
LICENSE = "Bar"
LIC_FILES_CHKSUM = "file://LICENSE;md5=a4a2bbea1db029f21b3a328c7a059172"
DEPENDS += "some-dependency"
---
or
recipe-a_1.0.bb
---
SUMMARY = "Foo"
LICENSE = "Bar"
LIC_FILES_CHKSUM = "file://LICENSE;md5=a4a2bbea1db029f21b3a328c7a059172"
DEPENDS:append = " some-dependency"
---
it works as expected.
Which bring me to my question:
Do we want to support these cases? even though it would mean that we
might have to patch a lot of recipes in multiple layers
Currently I more and more come to the conclusion that append/prepend/+=
should be the way to go, as otherwise globally inherited classes loose
variable settings without us noticing (except for build failures ofc).
This issue spreads even further as not only DEPENDS is affected, but
literally every hard assignment in a recipe that is also having a hard
assignment in a globally inherited class.
TBF
the correct fix would be
magic.bbclass
---
DEPENDS:append = " magic-dependency"
---
but unfortunately sometimes this is out of our control (as we don't want
to have bbclassappends for totally valid reasons)
Thoughts?
[1] https://lists.openembedded.org/g/openembedded-devel/topic/87562882#94227
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1372):
https://lists.openembedded.org/g/openembedded-architecture/message/1372
Mute This Topic: https://lists.openembedded.org/mt/87569589/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
