[PATCH 0/1] cooker.py: disignore explicitly requested packages

[PATCH 0/1] cooker.py: disignore explicitly requested packages

[Peter Seebach]

It turns out that ASSUMED_PROVIDED trumps command-line. This is surprising,
and more so because there is no diagnostic; the user is not told "this
package is being ignored", you just get told that 0 out of 0 tasks were
run, and all succeeded. We could add a diagnostic, but really, it seems as
though it makes sense to trust the user; a user who really wants to build
bzip2-native even though it is presumably provided by the host probably has
reasons. (Note: "The test plan says..." is a reason.)

The following changes since commit 23bd5300b4a99218a15f4f6b0ab4091d63a602a5:
  Richard Purdie (1):
        data_smart: Fix unanchored regexp causing strange parsing issue

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib seebs/cooker
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/cooker

Peter Seebach (1):
  cooker.py: Remove explicit build targets from the ignored list

 lib/bb/cooker.py |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

[PATCH 1/1] cooker.py: Remove explicit build targets from the ignored list

[Peter Seebach]

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(-)

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)
-- 
1.7.0.4

Re: [PATCH 1/1] cooker.py: Remove explicit build targets from the ignored list

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/1] cooker.py: Remove explicit build targets from the ignored list

[Peter Seebach]

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
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.

Re: [PATCH 1/1] cooker.py: Remove explicit build targets from the ignored list

[Chris Larson]

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.
-- 
Christopher Larson