All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: bitbake-devel@lists.openembedded.org
Cc: Richard Purdie <richard.purdie@intel.com>
Subject: Re: [PATCH 1/3] recipes: anonymous functions with priorities
Date: Mon, 09 Jan 2017 12:03:21 +0100	[thread overview]
Message-ID: <1483959801.2137.33.camel@intel.com> (raw)
In-Reply-To: <88c860131b153f5b95efb08c219d4dc5f0712f8b.1483696010.git.patrick.ohly@intel.com>

On Fri, 2017-01-06 at 10:50 +0100, Patrick Ohly wrote:
> The default priority is 100. Functions with higher values run later.
> 
> For example, rm_work.bbclass can use this to ensure that it runs
> later than other anonymous functions:
> 
> python __anonymous_rm_work() {
>     bb.build.addtask(....)
> }
> __anonymous_rm_work[priority] = "1000"

We discussed this a bit on chat, and there were concerns that priorities
are not defined well enough and will cause maintenance problems. Let me
add here that this was partly intentional: bitbake doesn't need to care
about specific priorities, that's something that the users of bitbake
(like OE-core) need to define. Admittedly my OE-core patch set did not
address that either, although it could be added with a documentation
patch.

As alternative, Richard suggested to add more events that will emit at
well-defined points in the processing of a recipe. However, as he said
himself, that then leads to the problem of ordering event handlers once
there is more then one handler who wants to run for a certain event.
IMHO that just reduces the scope of the problem, but does not really
solve it.

Basically, there would have to be a dedicated event for use only by
rm_work and nothing else, which kind of breaks the separation between
bitbake mechanisms and their use in meta data. Each time meta data needs
a new separate "slot", bitbake would have to be extended, which isn't
the case with the priority approach where each priority value already is
a separate slot.

Having said that, I don't have any strong opinion about this, I just
wanted to share some more thoughts on this.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





  reply	other threads:[~2017-01-09 11:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06  9:50 [PATCH 0/3] rm_work enhancements Patrick Ohly
2017-01-06  9:50 ` [PATCH 1/3] recipes: anonymous functions with priorities Patrick Ohly
2017-01-09 11:03   ` Patrick Ohly [this message]
2017-01-06  9:50 ` [PATCH 2/3] build.py: add preceedtask() API Patrick Ohly
2017-01-06  9:50 ` [PATCH 3/3] runqueue.py: alternative rm_work scheduler Patrick Ohly

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=1483959801.2137.33.camel@intel.com \
    --to=patrick.ohly@intel.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=richard.purdie@intel.com \
    /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.