On Wed, May 15, 2013 at 8:35 AM, Tomas Frydrych <tf+lists.yo...@r-finger.com> wrote: > Hi Paul, > > On 15/05/13 10:49, Paul Eggleton wrote: >>> It prevents efficiently supporting clutter on any real machine that does >>> not use mesa's GL, which means all machines not in meta-intel, and some >>> machines in meta-intel. This is the main issue, real HW support. >> >> How does it prevent that? Surely if machine-specific changes are required >> then >> they will be required on top of a separate layer as much as they are if the >> recipes remain in OE-Core. > > It could be all pulled together into the meta-clutter layer, the > supported BSPs and machines documented, etc, so that common machines > just work out of the box. We could have a dedicated mailing list, a bug > tracker, build a community around it, pull resources.
+1 >> The layer mechanism exists to allow specific >> recipes to be extended if needed. Having the recipes in OE-Core does not >> preclude their extension or replacement with newer versions elsewhere for >> those that need it. > > I have followed the model you advocate for over a year with clutter, and > it is a PITA, so I am thinking that perhaps there are others who are > doing the same and we could do it in one well known place. +1 >> You may well be right about the need to test on other GL implementations. >> That does not explain how moving them to a separate layer directly helps to >> address >> that need. You must also expect to make some changes to the recipes >> themselves, so what changes would you be making? > > It's not just about testing, you have to build it first: I would like to > see a set of recipes that can support a whole bunch of machines in the > public OE BSP layers out of the box: configs that work and make sense, > patches where needed, documentation, including documentation of BSP > specific issues. > > In the absence of a community-owned meta-clutter layer, if anyone is > stuck maintaining their own clutter recipes, I have a set at > https://github.com/Guacamayo/meta-clutter which can perhaps be of some use. +1 I share same feeling of Tomas and I agree that a new layer is the way to go. Having it in a specific layer will allow for more shared work and easy a community creation around it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core