Patchwork [bitbake-devel,1/1] cooker.py: Remove explicit build targets from the ignored list

login
register
mail settings
Submitter Peter Seebach
Date Aug. 8, 2012, 11:19 p.m.
Message ID <9005aeb8b41113f05121842055434fdeeda8c63c.1344467794.git.peter.seebach@windriver.com>
Download mbox | patch
Permalink /patch/34101/
State New
Headers show

Comments

Peter Seebach - Aug. 8, 2012, 11:19 p.m.
If something is in ASSUMED_PROVIDED, and a user tries to build it
explicitly, Nothing Happens. Bitbake just says it ran 0 out of 0
tasks. No diagnostics or explanations are offered.

In practice, the right thing is probably to assume that explicit
targets are intentional. So far as I can tell, cooker.buildTargets
is called only from the command line or from command.py, and both
cases seem to be explicit user actions.

Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
---
 lib/bb/cooker.py |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
Paul Eggleton - Aug. 9, 2012, 5:30 p.m.
On Wednesday 08 August 2012 18:19:42 Peter Seebach wrote:
> If something is in ASSUMED_PROVIDED, and a user tries to build it
> explicitly, Nothing Happens. Bitbake just says it ran 0 out of 0
> tasks. No diagnostics or explanations are offered.
> 
> In practice, the right thing is probably to assume that explicit
> targets are intentional. So far as I can tell, cooker.buildTargets
> is called only from the command line or from command.py, and both
> cases seem to be explicit user actions.

I'd rather we not change it to behave this way - the better approach would 
seem to me to be to just print a warning that the requested target is in 
ASSUME_PROVIDED and then not do anything else; if the user really wants to 
build the thing they can just remove it from ASSUME_PROVIDED.

If there is a genuine need to be able to force an item in ASSUME_PROVIDED to 
be built I'd probably want to hear a bit more background.

Cheers,
Paul
Peter Seebach - Aug. 9, 2012, 5:44 p.m.
On Thu, 9 Aug 2012 18:30:57 +0100
Paul Eggleton <paul.eggleton@linux.intel.com> wrote:

> I'd rather we not change it to behave this way - the better approach
> would seem to me to be to just print a warning that the requested
> target is in ASSUME_PROVIDED and then not do anything else; if the
> user really wants to build the thing they can just remove it from
> ASSUME_PROVIDED.

Removing things from ASSUME_PROVIDED can be a bit tricky, because they
can come from more than one place. And it may not be easy to see where
they came from. (In my most convenient build, there are at least two
files setting ASSUME_PROVIDED.)

> If there is a genuine need to be able to force an item in
> ASSUME_PROVIDED to be built I'd probably want to hear a bit more
> background.

I think it's not so much that there's a need, as that an explicit
statement should win over an assumption.

Analogy time!  Which is a better response to "-O2 -fno-inline":
1. Error message explaining that -O2 implied -finline, so you can't
do that.
2. The explicit flag overrides the flags implied by -O2.

I think of ASSUME_PROVIDED as meaning "if something thinks it needs
this, assume it's already available". So don't build it by-implication,
for instance as a dependency. Thus the name "ignored_dependencies".
Things specified by the user on the command line aren't dependencies,
though. They're explicit requests, and I think those should win. That
said... It might make sense to add a:

bb.note("Explicit target '%s' overriding ASSUME_PROVIDED." % foo)

so that people are aware that they are doing something unusual.

The specific case that got me looking at this actually involved the
bitbake -e feature, and on the one hand, seeing no output was
confusing, on the other hand, a diagnostic warning me that Something
Strange was involved would actually have been pretty informative.

-s
Chris Larson - Aug. 9, 2012, 5:54 p.m.
On Thu, Aug 9, 2012 at 10:44 AM, Peter Seebach
<peter.seebach@windriver.com> wrote:
> On Thu, 9 Aug 2012 18:30:57 +0100
> Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>
>> I'd rather we not change it to behave this way - the better approach
>> would seem to me to be to just print a warning that the requested
>> target is in ASSUME_PROVIDED and then not do anything else; if the
>> user really wants to build the thing they can just remove it from
>> ASSUME_PROVIDED.
>
> Removing things from ASSUME_PROVIDED can be a bit tricky, because they
> can come from more than one place. And it may not be easy to see where
> they came from. (In my most convenient build, there are at least two
> files setting ASSUME_PROVIDED.)

For what it's worth, I agree with Peter's approach on this. The user
should always be able to override assumptions. Explicit should win.
Technically variables can be explicitly set by the user as well, but
generally speaking I think we have always interpreted the command-line
as overriding the metadata when appropriate. Consider BBPKGS, which is
a list of providers to build if and only if the user doesn't specify
any.

Patch

diff --git a/lib/bb/cooker.py b/lib/bb/cooker.py
index 23fffc9..25d36d0 100644
--- a/lib/bb/cooker.py
+++ b/lib/bb/cooker.py
@@ -1129,6 +1129,11 @@  class BBCooker:
         universe = ('universe' in targets)
         targets = self.checkPackages(targets)
 
+        # Explicitly disignore things that have been requested.
+        for target in targets:
+            if target in self.status.ignored_dependencies:
+                self.status.ignored_dependencies.remove(target)
+
         def buildTargetsIdle(server, rq, abort):
             if abort or self.state == state.stop:
                 rq.finish_runqueue(True)