From: Andreas Oberritter <obi@opendreambox.org>
To: openembedded-core@lists.openembedded.org
Subject: Re: proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Date: Wed, 15 May 2013 13:20:09 +0000 [thread overview]
Message-ID: <51938B89.1060701@opendreambox.org> (raw)
In-Reply-To: <CAP9ODKqiTzMNpeMq_L7X40_omoNTXjAt3w8N8ykgPwjuEYr9Lg@mail.gmail.com>
On 15.05.2013 11:53, Otavio Salvador wrote:
> On Wed, May 15, 2013 at 8:35 AM, Tomas Frydrych
> <tf+lists.yocto@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.
I fail to see why the presence of meta-clutter contradicts keeping
clutter and related recipes in oe-core. If you add meta-clutter to your
layers, then its recipes will override those in oe-core anyway.
Of course, clutter recipes in oe-core could see some maintenance, but
that's IMO a different topic.
Regards,
Andreas
next prev parent reply other threads:[~2013-05-15 13:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 15:11 proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer Tomas Frydrych
2013-05-08 15:23 ` Phil Blundell
2013-05-08 16:34 ` Tomas Frydrych
2013-05-08 15:23 ` Richard Purdie
2013-05-08 16:20 ` Tomas Frydrych
2013-05-10 9:05 ` Richard Purdie
2013-05-10 10:56 ` Tomas Frydrych
2013-05-10 11:32 ` Richard Purdie
2013-05-10 16:39 ` Tomas Frydrych
2013-05-10 17:19 ` Richard Purdie
2013-05-10 20:22 ` Otavio Salvador
2013-05-10 20:37 ` Mark Hatle
2013-05-10 21:15 ` Otavio Salvador
2013-05-13 9:30 ` Tomas Frydrych
2013-05-13 15:41 ` Phil Blundell
2013-05-13 15:44 ` Burton, Ross
2013-05-14 9:14 ` Tomas Frydrych
2013-05-14 16:55 ` Paul Eggleton
2013-05-15 9:19 ` Tomas Frydrych
2013-05-15 9:49 ` Paul Eggleton
2013-05-15 11:35 ` Tomas Frydrych
2013-05-15 11:53 ` Otavio Salvador
2013-05-15 13:20 ` Andreas Oberritter [this message]
2013-05-15 14:09 ` Paul Eggleton
2013-05-15 16:34 ` Tomas Frydrych
2013-05-15 16:54 ` Otavio Salvador
2013-05-15 17:22 ` Paul Eggleton
2013-05-15 17:30 ` Richard Purdie
2013-05-15 17:36 ` Otavio Salvador
2013-05-15 18:24 ` Paul Eggleton
2013-05-15 19:28 ` Otavio Salvador
2013-05-15 20:49 ` Phil Blundell
2013-05-16 9:01 ` Tomas Frydrych
2013-05-16 10:35 ` Phil Blundell
2013-05-16 11:21 ` Tomas Frydrych
2013-05-16 14:35 ` Phil Blundell
2013-05-17 12:30 ` Paul Eggleton
2013-05-16 9:22 ` Tomas Frydrych
2013-05-15 19:43 ` Richard Purdie
2013-05-16 9:21 ` Tomas Frydrych
2013-05-10 21:07 ` Martin Jansa
2013-05-10 22:18 ` Richard Purdie
2013-05-11 20:39 ` Otavio Salvador
2013-05-11 21:49 ` Richard Purdie
2013-05-14 16:23 ` Philip Balister
2013-05-13 9:31 ` Tomas Frydrych
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51938B89.1060701@opendreambox.org \
--to=obi@opendreambox.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.