From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patrick Ohly <patrick.ohly@intel.com>,
"Burton, Ross" <ross.burton@intel.com>
Cc: Christopher Larson <chris_larson@mentor.com>,
OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 0/6] Add opengl to REQUIRED_DISTRO_FEATURES for some recipes
Date: Thu, 05 Jan 2017 08:51:05 +0000 [thread overview]
Message-ID: <1483606265.4367.75.camel@linuxfoundation.org> (raw)
In-Reply-To: <1483601563.28169.69.camel@intel.com>
On Thu, 2017-01-05 at 08:32 +0100, Patrick Ohly wrote:
> On Wed, 2017-01-04 at 23:49 +0000, Burton, Ross wrote:
> >
> >
> > On 4 January 2017 at 22:57, Christopher Larson <kergoth@gmail.com>
> > wrote:
> > These aren't buildable without it, and adding it fixes oe-
> > core
> > world builds
> > with nodistro (which does not have the opengl feature by
> > default).
> >
> >
> > Am I still the only person who thinks skipping of recipes should be
> > recursive, so if say libx11 throws a SkipRecipe then everything
> > else
> > that depends on it is also magically skipped?
> Not at all, I'd also prefer that. If recipe "foo" has some obscure
> conditions when it can be built, then repeating those conditions in
> any
> recipe depending on "foo" is a maintenance headache.
>
> Last time I brought this up, it was mentioned as advantage of the
> current approach that conditions are explicit and thus less
> surprising.
> There's some truth to that, but I don't believe that it outweighs the
> disadvantages.
Imagine for example that we accidentally add some condition which
results in 50% of the recipes being skipped. "bitbake world" would pass
if this auto-skipping functionality was implemented. I worry that it
would make it really easy to hide some subset of completely a non-
buildable recipes which we can't even easily identify other than
directly trying to build each target. We added something to avoid that
(the world target).
The second problem is the actual implementation of it. I've never come
up with a sane way to address this problem and give errors where people
would want them yet hide the cases where people really don't want to be
bothered, its very hard to make it work well at the bitbake level and
the code is already complex/fragile enough.
Considering this, marking things up explicitly has always seemed like
the right thing to do ever time I've looked further into this. If
someone has the time and wants to propose a solution, sure, but I think
there are other more important/pressing things to do.
Cheers,
Richard
next prev parent reply other threads:[~2017-01-05 8:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 22:57 [PATCH 0/6] Add opengl to REQUIRED_DISTRO_FEATURES for some recipes Christopher Larson
2017-01-04 22:57 ` [PATCH 1/6] waffle: add opengl to REQUIRED_DISTRO_FEATURES Christopher Larson
2017-01-04 22:57 ` [PATCH 2/6] piglit: " Christopher Larson
2017-01-04 22:57 ` [PATCH 3/6] libglu: " Christopher Larson
2017-01-04 23:34 ` Phil Blundell
2017-01-04 22:57 ` [PATCH 4/6] eglinfo-x11: " Christopher Larson
2017-01-04 22:57 ` [PATCH 5/6] packagegroup-self-hosted: " Christopher Larson
2017-01-04 22:57 ` [PATCH 6/6] packagegroup-core-lsb: " Christopher Larson
2017-01-04 23:49 ` [PATCH 0/6] Add opengl to REQUIRED_DISTRO_FEATURES for some recipes Burton, Ross
2017-01-05 0:52 ` Khem Raj
2017-01-05 1:13 ` Christopher Larson
2017-01-05 1:27 ` Khem Raj
2017-01-05 7:32 ` Patrick Ohly
2017-01-05 8:51 ` Richard Purdie [this message]
2017-01-05 10:35 ` Patrick Ohly
2017-01-05 8:54 ` Richard Purdie
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=1483606265.4367.75.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=chris_larson@mentor.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
--cc=ross.burton@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