All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Hongxu Jia <hongxu.jia@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] archiver: execute the probable tasks between do_unpack and do_patch
Date: Thu, 04 Dec 2014 09:56:12 +0000	[thread overview]
Message-ID: <1417686972.15614.51.camel@linuxfoundation.org> (raw)
In-Reply-To: <0f0404871231fee1f0f3d6448e843fa2089d7d90.1417594233.git.hongxu.jia@windriver.com>

On Wed, 2014-12-03 at 16:16 +0800, Hongxu Jia wrote:
> While archiver inherited, we edit a recipe (such
> as gzip) to insert four tasks between do_patch and
> do_unpack:
> ...
> addtask test1 after do_unpack before do_patch
> addtask test2 after do_unpack before do_test1
> addtask test3 after do_test2 before do_test1
> addtask test4 after do_test2 before do_test1
> ...
> 
> While building the recipe, the archiver will
> missing these four task in do_unpack_and_patch.
> Because it is hardcoded to execute do_unpach and
> do_patch, did not consider the probable tasks
> between them.
> 
> We make use of the value of _task_deps which
> provided by metadata to compute the probable
> tasks between do_unpack and do_patch and execute
> them.

_task_deps is not provided by the metadata, its a bitbake internal
variable and it should not be being used in public API like this. The
bitbake maintainers reserve the right to change structure and existence
of _task_deps freely. So this patch *cannot* merge in this form.

I do appreciate the problem you're trying to solve and that its a hard
one to deal with.

We should probably add some API to bb.build which allows the code to
query information about tasks. I would prefer to only expose the
information we need (the parents) rather than the whole contents of
_task_deps since that may change over time. The main reason that
structure exists at all is a performance optimisation inside the core of
bitbake.

Thinking about this further, have you looked at BB_TASKDEPDATA? You may
well be able to extract the information you need from that and that *is*
public API.

Cheers,

Richard





  reply	other threads:[~2014-12-04  9:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03  8:16 [PATCH 0/1] fix archiver missing tasks between do_unpack and do_patch Hongxu Jia
2014-12-03  8:16 ` [PATCH 1/1] archiver: execute the probable " Hongxu Jia
2014-12-04  9:56   ` Richard Purdie [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-12-05  6:16 [PATCH V2 0/1] fix archiver missing " Hongxu Jia
2014-12-05  6:16 ` [PATCH 1/1] archiver: execute the probable " Hongxu Jia

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=1417686972.15614.51.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=hongxu.jia@windriver.com \
    --cc=openembedded-core@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.