Re: [bitbake-devel] noexec varflag behavior vs documentation?

[Quentin Schulz <quentin.schulz@theobroma-systems.com>]

Hi all,

On Tue, Oct 26, 2021 at 06:52:13PM -0400, Scott Murray wrote:
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_bitbake_bitbake-2Duser-2Dmanual_bitbake-2Duser-2Dmanual-2Dmetadata.html-3Fhighlight-3Dnoexec-23variable-2Dflags&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=3MyfDNSSpgdyktGkBPxMbSTE5f_Zhd1LPfnJpB5RZKj7Y_kz1mNBKHiDRQIcQqVa&s=Ft7skkAcV-DVdN9pgL86P8uC4YXvmaZAAxv_Z_b2RfI&e= 
> > )
> > > > > >
> > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.yoctoproject.org_show-5Fbug.cgi-3Fid-3D13808&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=3MyfDNSSpgdyktGkBPxMbSTE5f_Zhd1LPfnJpB5RZKj7Y_kz1mNBKHiDRQIcQqVa&s=5AlgH0WAkrLyi_26gPtB36P6DpYuzhOLhAqWG9JYPUs&e= 
> > > >
> > > > I don't see the discussed deprecation warning change in master,
> > though, so
> > > > I'm guessing it got dropped.
> > >
> > >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.yoctoproject.org_cgit.cgi_poky_commit_-3Fid-3D66f22c0bd19a81ee7ccb49543f24a4f90fc012ba&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=3MyfDNSSpgdyktGkBPxMbSTE5f_Zhd1LPfnJpB5RZKj7Y_kz1mNBKHiDRQIcQqVa&s=2DxZLnNctIoF2d_HHDemxGxT74p51rChV-ZLG9bJz84&e= 
> > >
> > > 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).
> 

I'd keep that 1 is setting it as this is the expected behavior. I would
add a note that "due to a bug <insert link>, undoing a [noexec] requires to
unset the variable like so: <current way of undoing this varflag>" and
we remove this note once the bug is fixed (can already say we'll forget
but eh :) ).

Cheers,
Quentin