Re: [PATCH 0/6] Add opengl to REQUIRED_DISTRO_FEATURES for some recipes

[Patrick Ohly <patrick.ohly@intel.com>]

On Thu, 2017-01-05 at 08:51 +0000, Richard Purdie wrote:
> 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).

Shouldn't it be caught by QA when expected functionality suddenly
disappears? But I guess that would only work in a perfect world; in
practice, QA coverage isn't sufficient and some recipes are indeed
merely in a "we know it compiles" state.

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

How about a compromise: instead of repeating some (potentially complex)
checks in every recipe affected by this, could we have a "skip recipe
foo if dependencies are unavailable" check?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.