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 <[email protected]> > > > 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. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
