From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patrick Williams <patrick@stwcx.xyz>,
Alexander Kanavin <alex.kanavin@gmail.com>
Cc: Lean Sheng Tan <sheng.tan@9elements.com>,
Ross Burton <Ross.Burton@arm.com>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>,
"Hansen, Alexander" <alexander.hansen@9elements.com>,
John Chung <John.Chung@arm.com>
Subject: Re: [OE-core] btrfs-tools-native build python error
Date: Thu, 02 May 2024 14:50:51 +0100 [thread overview]
Message-ID: <1bb12e6054301a5d3390991e1d1f0e013036a816.camel@linuxfoundation.org> (raw)
In-Reply-To: <ZjOXpREhYRo2vfzX@heinlein.vulture-banana.ts.net>
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 <patrick@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
next prev parent reply other threads:[~2024-05-02 13:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAMWxwJ0znPDyQAKAwv8PL9GwyCCEpW9+2SDmXsygNyK26_xF-A@mail.gmail.com>
2024-04-25 12:29 ` btrfs-tools-native build python error Lean Sheng Tan
2024-04-25 16:33 ` [OE-core] " Ross Burton
2024-04-25 16:45 ` Lean Sheng Tan
[not found] ` <17C993B983870D20.19690@lists.openembedded.org>
2024-04-25 17:40 ` Lean Sheng Tan
2024-05-01 21:27 ` Patrick Williams
2024-05-02 9:28 ` Alexander Kanavin
2024-05-02 12:52 ` Patrick Williams
2024-05-02 12:57 ` Alexander Kanavin
2024-05-02 13:01 ` Alexander Kanavin
2024-05-02 13:06 ` Patrick Williams
2024-05-02 13:34 ` Alexander Kanavin
2024-05-02 13:39 ` Patrick Williams
2024-05-02 13:50 ` Richard Purdie [this message]
2024-05-02 13:34 ` Patrick Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1bb12e6054301a5d3390991e1d1f0e013036a816.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=John.Chung@arm.com \
--cc=Ross.Burton@arm.com \
--cc=alex.kanavin@gmail.com \
--cc=alexander.hansen@9elements.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick@stwcx.xyz \
--cc=sheng.tan@9elements.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).