[OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Paul Eggleton
paul.eggleton at linux.intel.com
Tue May 14 16:55:40 UTC 2013
On Tuesday 14 May 2013 10:14:20 Tomas Frydrych wrote:
> On 13/05/13 16:41, Phil Blundell wrote:
> > It seems a bit hyperbolic to claim that testing clutter is impossible
> > without GPU hardware (either real or emulated). The majority of the
> > code even in cogl, and virtually all the code in clutter itself, is
> > mostly independent of the underlying GL implementation. From the point
> > of view of testing whether clutter basically "works" and is correctly
> > built/packaged it seems as though this ought to be quite sufficient.
>
> There are too separate issues: testing clutter itself, and using clutter
> to test other parts of the graphics stack.
>
> Re the former, all you can say after testing cogl/clutter against mesa
> software rasterizer is that a particular configuration and a particular
> backend (in oe-core that would be the GLX backend) work with mesa
> software rasterizer. This says nothing about any other configuration,
> with any other backend or whether it works with any other GL/GLES
> implementation.
>
> In reality, cogl/clutter need patches to build against the likes of TI's
> GLES (e.g., Beagleboard) or to work on the likes of RaspberryPi, and
> these patches cannot be included in oe-core, of course, because oe-core
> knows nothing of such machines.
Having clutter in OE-Core does not preclude such testing with additional BSPs,
and I'm unclear on how moving it out to another layer helps at all with this
specific issue.
> Then there are little annoyances, like
> the fact that over the last year or so, clutter has tended to have a
> dependency on a specific but mostly random versions of libxkbcommon
> (from what I can gather, determined more then anything by whatever the
> Fedora packager happened to package and what version of Fedora the
> clutter maintainer was using), or Clutter's customary insistence on as
> recent glib as you can get. This can all be nicely encapsulated in small
> layer.
This could present a problem. What if I want Clutter but I don't want the
latest version of glib, but instead the version that is being shipped with OE-
Core that is tested with the other pieces of the system that depend upon it
(especially given glib has recent history of breaking other packages)? Surely
the safest alternative is the last stable version of Clutter that works with
that version of glib? That would make it difficult to depend upon an external
layer that provides its own newer version of glib would it not?
There's no denying that the maintenance of the Clutter recipes in OE-Core has
slipped. I don't think that is an argument in itself to split them out, that
just means we need to recognise that and maintain those recipes more
effectively. It's not a case where we've missed the release because it was too
close, we've not updated it for longer than that.
Honestly I think if Clutter continues to be something that people are using to
develop applications we're much better off with the "canonical" stable version
being in OE-Core.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-core
mailing list