Hi all,
thanks for sharing your thoughts.
My takeaway of the discussion is, that we don't want to fix badly coded
class code in the recipe scope - that's fine.
On the other hand we might need to have a form on introspection on
class/conf code (so we might be able to track down those issues) - maybe
something like an insane-class functionality (from my current
unterstanding as the rules apply to every user of bitbake, this could be
done as part of the parsing process within bitbake itself)
Furthermore I really would like to see something like a table
| - | inherit | pn-override in conf | using INHERIT | bbappend |
| ------ | ------- | ------------------- | ------------- | -------- |
| = | | | | |
| += | | | | |
| append | | | | |
| remove | | | | |
| ?= | | | | |
| ??= | | | | |
where the use cases of the operations are briefly described.
That should then be the basis for documentation and further discussion.
I'm willing to contribute to this documentation if one could come up
with a location where we want to have that WIP document. open-embedded
WIKI? google docs?
Regards
Konrad
On 08.12.21 05:21, Douglas Royds wrote:
On 8/12/21 1:02 pm, Richard Purdie wrote:
On Tue, 2021-12-07 at 11:09 -0800, Andre McCurdy wrote:
On Tue, Dec 7, 2021 at 9:58 AM Richard Purdie <[email protected]> wrote:
On Tue, 2021-12-07 at 17:53 +0000, Ross Burton wrote:
On Tue, 7 Dec 2021 at 17:15, Konrad Weihmann
<[email protected]> wrote:
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?
Personally, I'd say that's the correct fix, and any class that
DEPENDS= is just broken. Recipes should be able to do DEPENDS= because
that's convenient, and classes should use DEPENDS:append.
This is complicated by the issue that such appends are near
impossible to
override, so you end up with the conditional bits in
autotools/base.bbclass
adding variables to set to stop the behaviour. Classes should be a
starting
point for things, not a hard requirement the recipe can't override.
If the goal is to let the recipe undo changes made by a .bbclass then
one easy solution is indirection. The class can use:
MAGIC_DEPENDS ?= "foo"
DEPENDS:append = " ${MAGIC_DEPENDS}"
Recipes can then override MAGIC_DEPENDS as required.
That does still feel like we're admitting our syntax is broken though :(
I'd vote for this option.
I don't see it as an admission of failure at all, on the contrary it
says, "Default behaviour is to append this, but we've given you a
setting that you can manipulate if you need to."
FWIW, we also have quite a few :remove(s) in our proprietary layer,
mostly in .bbappend files.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1381):
https://lists.openembedded.org/g/openembedded-architecture/message/1381
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]]
-=-=-=-=-=-=-=-=-=-=-=-
