[OE-core] how many ways to delete/de-activate a recipe's task?

Robert P. J. Day rpjday at crashcourse.ca
Thu Mar 12 07:52:24 UTC 2015


On Wed, 11 Mar 2015, Richard Purdie wrote:

> On Wed, 2015-03-11 at 12:22 -0500, Mark Hatle wrote:
> > On 3/11/15 11:30 AM, Robert P. J. Day wrote:
> > >
> > >   i recall that richard purdie might have explained this once but i
> > > have no idea where that post is and i need to add something to it,
> > > anyway ... how many ways are there to "delete" a task from a recipe,
> > > and what are the differences?
> > >
> > >   so far, i've seen:
> > >
> > > 1) bitbake supports a "deltask" directive
> >
> > The task and all it's dependencies go away.  So anything dependent on it and the
> > things it depends on, are no longer dependent.
> >
> > > 2) you can use the [noexec] task flag
> >
> > The task and it's dependencies remain, but nothing is executed.
> >
> > > 3) i've also seen redefining the task with a no-op ":" command
> >
> > The task is executed and does nothing.  (I believe this dumps a stamp file and
> > the noexec does not.. but I may be wrong.)
>
> What Mark said. 3) is the old way of doing 2), we added 2) to make
> it more efficient since there is no task execution overhead (which
> at one point was measurable, it may be less so now).

  so that first part -- that 2) is a newer, tidier(?) way of doing 3)
-- is pretty much what i remember from once upon a time. good.

  as for 1), i'm still confused by that explanation. say we have the
dependency chain A -> B -> C ... A depends on B which depends on C. if
i "deltask B", then any dependency links which involve B will
disappear, both incoming and outgoing in the DAG. but will A be
adjusted to now depend on C? (i'm guessing not, just want to be sure.)

  finally, is it just a matter of personal taste whether one deletes a
task using "deltask" or uses [noexec]? i'm looking at examples under
OE and here are a couple.

  clearly, for image.bbclass, there are a *pile* of tasks that are not
relevant, so the following makes sense:

meta/classes/image.bbclass:do_fetch[noexec] = "1"
meta/classes/image.bbclass:do_unpack[noexec] = "1"
meta/classes/image.bbclass:do_patch[noexec] = "1"
meta/classes/image.bbclass:do_configure[noexec] = "1"
meta/classes/image.bbclass:do_compile[noexec] = "1"
meta/classes/image.bbclass:do_install[noexec] = "1"
meta/classes/image.bbclass:do_populate_sysroot[noexec] = "1"
meta/classes/image.bbclass:do_package[noexec] = "1"
meta/classes/image.bbclass:do_package_qa[noexec] = "1"
meta/classes/image.bbclass:do_packagedata[noexec] = "1"
meta/classes/image.bbclass:do_package_write_ipk[noexec] = "1"
meta/classes/image.bbclass:do_package_write_deb[noexec] = "1"
meta/classes/image.bbclass:do_package_write_rpm[noexec] = "1"
meta/classes/image.bbclass:do_bundle_initramfs[noexec] = "1"

  similarly, for native.bbclass, the following also makes sense, but
uses "deltask":

meta/classes/native.bbclass:deltask package
meta/classes/native.bbclass:deltask packagedata
meta/classes/native.bbclass:deltask package_qa
meta/classes/native.bbclass:deltask package_write_ipk
meta/classes/native.bbclass:deltask package_write_deb
meta/classes/native.bbclass:deltask package_write_rpm
meta/classes/native.bbclass:deltask package_write

  so why does the first use [noexec] and the second use deltask? is
there a functional difference?

rday

p.s. i believe i appreciate the difference in *mechanics* of the
above. [noexec] doesn't affect the DAG of task dependencies, it simply
turns off the execution of that recipe-specific task, while "deltask"
affects the actual underlying task DAG.

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================



More information about the Openembedded-core mailing list