[OE-core] [PATCH 0/6] Add opengl to REQUIRED_DISTRO_FEATURES for some recipes

Richard Purdie richard.purdie at linuxfoundation.org
Thu Jan 5 08:51:05 UTC 2017


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 at 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



More information about the Openembedded-core mailing list