Yocto Project Documentation
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: rpjday@crashcourse.ca,
	YP docs mailing list <docs@lists.yoctoproject.org>
Subject: Re: [docs] more docs curiosity: "inherit_defer" in the BB manual
Date: Wed, 09 Jul 2025 14:34:15 +0100	[thread overview]
Message-ID: <63ac037ab19af1c1fa58290261318bebcc2db6be.camel@linuxfoundation.org> (raw)
In-Reply-To: <764e27fc-0e53-777a-3427-4989e8d79403@crashcourse.ca>

On Wed, 2025-07-09 at 09:31 -0400, Robert P. J. Day via
lists.yoctoproject.org wrote:
> 
> here:
> 
> https://docs.yoctoproject.org/bitbake/2.12/bitbake-user-manual/bitbake-user-manual-metadata.html#inherit-defer-directive
> 
> that section strongly suggests that the sole reason to use
> "inherit_defer" is that you want to inherit some class, but you're
> not
> sure which class *yet*, so you use a variable that will, at some
> point, be set before parsing is complete. or possibly it will involve
> a programmatic condition.
> 
>   so what is the purpose of using "inherit_defer" on a fixed bbclass
> name such as this?
> 
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/qemu/qemu-native.inc#n3
> 
> what is the rationale of inherit_defer'ing a fixed class name? or is
> there more to this that i'm missing?

native has to be last. That means it has to be deferred.

I think bitbake now happens to handle this magically after more recent
changes, just to complicate the story.

Cheers,

Richard


  reply	other threads:[~2025-07-09 13:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-09 13:31 more docs curiosity: "inherit_defer" in the BB manual Robert P. J. Day
2025-07-09 13:34 ` Richard Purdie [this message]
2025-07-09 14:20   ` [docs] " Robert P. J. Day
2025-07-14 14:40     ` Quentin Schulz

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=63ac037ab19af1c1fa58290261318bebcc2db6be.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=docs@lists.yoctoproject.org \
    --cc=rpjday@crashcourse.ca \
    /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