From: Rolf Leggewie <no2spam@nospam.arcornews.de>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC] policy about nonworking recipes
Date: Thu, 21 May 2009 23:12:49 +0200 [thread overview]
Message-ID: <gv4g4j$2r4$1@ger.gmane.org> (raw)
In-Reply-To: <gv4ea5$sbp$1@ger.gmane.org>
Hi,
Koen Kooi wrote:
> On 21-05-09 22:20, Rolf Leggewie wrote:
>
>> I think that, eventually, "bitbake world" should be working again and
>> usable as a test case.
>
> A laudable goal...
But not the only one. And essentially not even the main motivation
behind this. For lack of a better description I'd say it's "OE should
just work" instead of "OE has a gazillion recipes to build a
fantastillion packages"*.
* "but most of them won't build for you and you only find out after
compiling for 48 hours, sorry"
>> I suggest to use COMPATIBLE_MACHINE because I
>> assume that to be the more common issue.
>
> NAK, we have a perfectly good EXCLUDE_FROM_WORLD = "1" for that, which
> is already used in lots (well, 23) recipes and classes.
Any bb in the repo should be buildable or clearly say where it is not
and exclude itself from any build where it isn't suitable.
EXCLUDE_FROM_WORLD does not do that, so it's not a solution.
DEFAULT_PREFERENCE -1 would be feasible but that just says "doesn't
work" whereas COMPATIBLE_MACHINE is more than likely to be a step in the
right direction (again, assuming most situations where things don't work
here but work for somebody else will be machine-dependent). The
semantics of COMPATIBLE_MACHINE being "no compatible machines known to
the last committer". If it turns out to be a host-dependent issue,
instead, then the next commit should replace the COMPATIBLE_MACHINE line
with one listing only the COMPATIBLE_HOSTs.
I'm all ears for differing suggestions, but EXCLUDE_FROM_WORLD isn't
really a solution.
Regards
Rolf
next prev parent reply other threads:[~2009-05-21 21:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 20:20 [RFC] policy about nonworking recipes Rolf Leggewie
2009-05-21 20:41 ` Koen Kooi
2009-05-21 21:05 ` Philip Balister
2009-05-21 21:12 ` Christopher Larson
2009-05-21 21:36 ` Rolf Leggewie
2009-05-21 21:12 ` Rolf Leggewie [this message]
2009-05-21 21:46 ` Koen Kooi
2009-05-21 21:53 ` Philip Balister
2009-05-21 22:59 ` Rolf Leggewie
2009-05-21 23:29 ` Philip Balister
2009-05-21 23:46 ` Rolf Leggewie
2009-05-22 7:57 ` Yuri Bushmelev
2009-05-21 21:16 ` Rolf Leggewie
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='gv4g4j$2r4$1@ger.gmane.org' \
--to=no2spam@nospam.arcornews.de \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/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.