On Thu, 2011-09-22 at 13:32 +0200, Koen Kooi wrote: > Op 16 sep 2011, om 15:38 heeft Richard Purdie het volgende geschreven: > > > On Fri, 2011-09-16 at 12:06 +0100, Phil Blundell wrote: > >> On Fri, 2011-09-16 at 12:00 +0100, Richard Purdie wrote: > >>> On Fri, 2011-09-16 at 12:19 +0200, Martin Jansa wrote: > >>>> On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote: > >>>>> On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote: > >>>>>> some text here > >>>>> > >>>>> It took all my restraint to not just reply with: > >>>>> """ > >>>>> NAK > >>>>> > >>>>> <insert reason for NAK here, I can't be bothered to type it> > >>>>> """ > >>>>> > >>>>> We've been around in a few circles with this. The problem is > >>>>> that if we > >>>>> apply this patch we have no clue which gst-plugin from the good, > >>>>> the bad > >>>>> and the ugly provides something you're after to include in an > >>>>> image. > >>>>> This results in bitbake being pretty clueless about whether a > >>>>> given > >>>>> build will succeed or not. In general I'm not a fan of having > >>>>> non-deterministic builds as they tend to annoy users. > >>>>> > >>>>> If this position isn't acceptable then we'll probably have to > >>>>> move to a > >>>>> situation where we list which plugins each of the packages > >>>>> builds and > >>>>> drop the dyanmic provides. That is a maintenance pain and I > >>>>> don't take > >>>>> that step lightly but I don't see any other options. I'm open to > >>>>> suggestions though. > >>>> > >>>> Something like: > >>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html > >>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html > >>>> ? > >>> > >>> Yes. I'd probably have written separate .inc files to simplify the > >>> script but I'm thinking along those lines. I'm not particularly > >>> happy > >>> about it but I don't see many other options. > >> > >> Last time this issue came up we talked about simply merging the - > >> good, > >> -bad and -base plugins into a single recipe (since there appears to > >> be > >> no very compelling reason to keep them separate) and just leaving the > >> -ugly ones on their own. That still seems to me as though it is the > >> best way of making a lot of that complexity just go away. Then > >> something like Martin's script could be used to figure out the > >> (mostly > >> static, with a bit of luck) split between -ugly and the rest. > > > > When put like this it doesn't sound so attractive since you need the > > scripts for ugly anyway. Keeping them separate does actually help > > build > > time at least since the plugins are one of the last things to get > > built > > and if merged, you also have to merge all the dependencies, > > compounding > > the build time. > > If someone can tell me which solution is preferred I can start working > on patches :)
I'm preferring the script generating the list of provides for the gstreamer recipe... Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
