bitbake-devel.lists.openembedded.org archive mirror
 help / color / mirror / Atom feed
From: Scott Murray <scott.murray@konsulko.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Konrad Weihmann <kweihmann@outlook.com>,
	bitbake-devel <bitbake-devel@lists.openembedded.org>
Subject: Re: [bitbake-devel] noexec varflag behavior vs documentation?
Date: Tue, 26 Oct 2021 18:52:13 -0400	[thread overview]
Message-ID: <CAFrvZPWhg6hw0yirR-Sq5=+hJwhuwOg7B+uH1ZYicDBoY18e2g@mail.gmail.com> (raw)
In-Reply-To: <8bd2e9ff001261ae11beb8794f843965088c3162.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

On Tue, Oct 26, 2021 at 6:44 PM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Tue, 2021-10-26 at 23:23 +0100, Richard Purdie via
> lists.openembedded.org
> wrote:
> > On Tue, 2021-10-26 at 15:54 -0400, Scott Murray wrote:
> > > On Tue, 26 Oct 2021, Konrad Weihmann wrote:
> > >
> > > > On 26.10.21 17:57, Scott Murray wrote:
> > > > > As I brought up on the dev call earlier, the task noexec varflag
> > > > > documentation says:
> > > > >
> > > > > * [noexec]: When set to “1”, marks the task as being empty, with no
> > > > > execution required. You can use the [noexec] flag to set up tasks
> as
> > > > > dependency placeholders, or to disable tasks defined elsewhere
> that are
> > > > > not needed in a particular recipe.
> > > > >
> > > > > (from:
> > > > >
> https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html?highlight=noexec#variable-flags
> )
> > > > >
> > > > > However, as I discovered yesterday, the reality is that it being
> set to
> > > > > any value at all disables execution, which Richard mentioned on
> the dev
> > > > > call helps with performance.  The question Richard asked me to
> bring here
> > > > > is whether the documentation should be updated, or if the behavior
> should
> > > > > be changed to match it?  I do not have a strong opinion either
> way, but
> > > > > would like this resolved somehow to avoid others spending time
> scratching
> > > > > their heads like I did for a bit yesterday.
> > > >
> > > > As I stumbled upon the very same, I'd love to see the docu being
> updated - I
> > > > mean implicitly it already does that as noexec can be only
> deactivated by
> > > > putting no value in it - but both cases should be properly
> documented IMO
> > >
> > > Chris mentioned to me OOB this existing Bugzilla:
> > >
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13808
> > >
> > > I don't see the discussed deprecation warning change in master,
> though, so
> > > I'm guessing it got dropped.
> >
> >
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=66f22c0bd19a81ee7ccb49543f24a4f90fc012ba
> >
> > Is that code working?
>
> I did check and with do_compile[noexec] = "0" in the bash recipe, I see:
>
> WARNING: /xxx/meta/recipes-extended/bash/bash_5.1.8.bb: In a future
> version of BitBake, setting the 'noexec' flag to something other than '1'
> will result in the flag not being set. See YP bug #13808
>
> so it does appear to.
>

Yes, I did just try it here as well.  I've been working on dunfell and
missed it in master
when I looked through git grep, my apologies.  I guess there's still the
questions of
just when the deprecation takes effect and if anything should be done with
respect to
the documentation in the meantime (since it could IMO be argued it's
incorrect ATM).

Scott

[-- Attachment #2: Type: text/html, Size: 4411 bytes --]

  parent reply	other threads:[~2021-10-26 22:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d248a56-a985-952c-363c-7a642761c2b6@spiteful.org>
2021-10-26 17:18 ` [bitbake-devel] noexec varflag behavior vs documentation? Konrad Weihmann
     [not found]   ` <7aabfa2b-2019-2dfb-3ae0-3ace4c4638d@spiteful.org>
     [not found]     ` <16B1B4E0DFE93958.19566@lists.openembedded.org>
     [not found]       ` <8bd2e9ff001261ae11beb8794f843965088c3162.camel@linuxfoundation.org>
2021-10-26 22:52         ` Scott Murray [this message]
2021-10-27  9:53           ` 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='CAFrvZPWhg6hw0yirR-Sq5=+hJwhuwOg7B+uH1ZYicDBoY18e2g@mail.gmail.com' \
    --to=scott.murray@konsulko.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=kweihmann@outlook.com \
    --cc=richard.purdie@linuxfoundation.org \
    /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 NNTP newsgroup(s).