From: Peter Seebach <peter.seebach@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH 1/1] cooker.py: Remove explicit build targets from the ignored list
Date: Thu, 9 Aug 2012 12:44:25 -0500 [thread overview]
Message-ID: <20120809124425.797f12fa@e6410-2> (raw)
In-Reply-To: <1356576.1YqSGvrhCQ@helios>
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.
next prev parent reply other threads:[~2012-08-09 17:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 23:19 [PATCH 0/1] cooker.py: disignore explicitly requested packages Peter Seebach
2012-08-08 23:19 ` [PATCH 1/1] cooker.py: Remove explicit build targets from the ignored list Peter Seebach
2012-08-09 17:30 ` Paul Eggleton
2012-08-09 17:44 ` Peter Seebach [this message]
2012-08-09 17:54 ` Chris Larson
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=20120809124425.797f12fa@e6410-2 \
--to=peter.seebach@windriver.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=paul.eggleton@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox