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