On Thu, 2024-05-02 at 08:39 -0500, Patrick Williams wrote: > On Thu, May 02, 2024 at 03:34:43PM +0200, Alexander Kanavin wrote: > > On Thu, 2 May 2024 at 15:06, Patrick Williams <patr...@stwcx.xyz> wrote: > > > > > This is almost never correct and there is not a single example of it in > > > poky. There _are_ examples of exactly what I wrote. > > > > > > If you do `PACKAGECONFIG:class-target:remove` and there is not already > > > an explicit `PACKAGECONFIG:class-target` defined, this in effect creates > > > a _new_ _empty_ variable `PACKAGECONFIG:class-target`. This is nearly > > > never what you want. You typically want to take the base contents of > > > `PACAKGECONFIG` and remove something from it explicitly for the > > > `class-target` class. What I wrote is exactly how to do that and what > > > there are multiple examples of in poky (see tclibc-barmetal.inc, > > > no-gplv3.inc, meta-openembedded uim_1.8.8.bb). > > > > Right, I just reproduced this. To me this looks like conditions in > > inherit_defer operate on PACKAGECONFIG value that is assembled without > > considering class overrides, and that might be a bug. > > Worse is that it seems to always operate on the `class-target` > overrides. It is as if, at the point that `inherit_defer` evaluates, it > is not known if it is a native or target class and so the default > `CLASSOVERRIDE` from base.bbclass takes precedence over what comes from > native.bbclass. > > > > > How to see the issue: > > PACKAGECONFIG:remove:class-target:pn-btrfs-tools = "python" > > > > bitbake btrfs-tools-native > > > > You might be able to work around this by avoiding :remove and setting > > PACKAGECONFIG directly.
It is an ordering issue. The trouble is that class-native comes from native.bbclass which is a BBCLASSEXTEND. The class extension code happens right at the end of parsing (for obvious reasons) and this is after inherit_defer is evaluated. So it is a rather horrible side effect of how the class overrides work. Sadly inline python like this is difficult to defer indefinitely and is why immediate expansion is generall painful and a bad idea :( I'm not entirely sure we can fix that. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#198924): https://lists.openembedded.org/g/openembedded-core/message/198924 Mute This Topic: https://lists.openembedded.org/mt/105729019/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
