Bug 13808 - do_task[noexec] = "" marks task noexec, which is inconsistent with docs
Summary: do_task[noexec] = "" marks task noexec, which is inconsistent with docs
Status: IN PROGRESS IMPLEMENTATION
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: 3.0.1
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 6.2
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2020-02-21 20:23 UTC by Chris Laplante
Modified: 2026-10-01 15:48 UTC (History)
8 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Laplante 2020-02-21 20:23:49 UTC
The manual says that to make a task noexec, you need to set its noexec flag to "1". But as currently implemented, setting the flag to anything (including an empty string) will cause it to be noexec. This is problematic because it makes conditional noexec impossible (at least without an anonymous Python function), e.g.:

do_task[noexec] = "${@"1" if condition else ""}"

This is because getTasks (a local function inside add_tasks of lib/bb/build.py) only checks to see if the flag is present. It doesn't validate the contents.

This is also true of nostamp and fakeroot.

I suggest teaching getTasks to check for "1" for noexec, nostamp, and fakeroot, and reject other values.
Comment 1 Randy MacLeod 2020-02-27 15:45:50 UTC
Richard is concerned that this could break other layers. Have you tested a large collection of YP layer with a fix? A 3.1 fix is possible but we need to be reassured about the impact.
Comment 2 Chris Laplante 2020-02-27 15:52:31 UTC
(In reply to comment #1)
> Richard is concerned that this could break other layers. Have you tested a
> large collection of YP layer with a fix? A 3.1 fix is possible but we need
> to be reassured about the impact.

I have not. Perhaps for 3.1 we can "deprecate" it by adding a bb.warn when a noexec flag is set to anything other than "1"? This should give some visibility to how many recipes are actually relying on it. Then in 3.2 we could consider fixing it entirely.
Comment 3 Randy MacLeod 2020-02-28 17:49:05 UTC
Chris, I guess the next step is to send a patch that does the deprecation for 3.1 so see if anyone in the wider community objects.
Comment 4 Randy MacLeod 2021-04-29 15:47:40 UTC
Chris, did this happen ? If not please move to 3.4. -- Randy
Comment 5 Chris Laplante 2021-08-17 15:52:17 UTC
Sorry for the delay. The deprecation warning is implemented in master-next as of June 2nd, 2021. I would propose pushing out completely "fixing" this (namely, changing it so that setting to something other than '1' has no effect) until a later milestone to give people some time to migrate. Maybe 3.5 or 3.6?
Comment 6 Randy MacLeod 2022-11-03 15:14:52 UTC
Richard said he'd look at this bug.
Comment 7 Hiago De Franco 2026-02-22 21:39:10 UTC
Hello, I would like to work on this bug. I hit this warning and looks like something cool to work on, and for me to learn. Can anybody help me about the progress and the current situation?

Thanks