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