[PATCH 1/3] cogl-1.0: put each library into its own package

[PATCH 1/3] cogl-1.0: put each library into its own package

[Andreas Oberritter]

This allows to install cogl-gles2 and cogl-pango only when needed and
enables Debian package renaming. This stops cogl-pango from dragging
in unwanted runtime dependencies, if cogl-pango isn't used.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/recipes-graphics/cogl/cogl-1.0.inc | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc b/meta/recipes-graphics/cogl/cogl-1.0.inc
index 55eb003..8400668 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -9,7 +9,10 @@ SRC_URI += "file://cogl_fixed_mul-constraint.patch \
 inherit clutter
 
 DEPENDS = "pango glib-2.0 gdk-pixbuf"
-PACKAGES =+ "${PN}-examples"
+PACKAGES =+ "${PN}-examples \
+             libcogl libcogl-dev \
+             libcogl-gles2 libcogl-gles2-dev \
+             libcogl-pango libcogl-pango-dev"
 AUTOTOOLS_AUXDIR = "${S}/build"
 
 # Extra DEPENDS for PACKAGECONFIG
@@ -54,3 +57,25 @@ PACKAGECONFIG ??= "gl \
                    ${@base_contains('DISTRO_FEATURES', 'x11', 'glx', '', d)}"
 
 FILES_${PN}-examples = "${bindir}/* ${datadir}/cogl/examples-data/*"
+FILES_libcogl = "${libdir}/libcogl${SOLIBS}"
+FILES_libcogl-dev = "${includedir}/cogl/cogl \
+                     ${libdir}/libcogl${SOLIBSDEV} \
+                     ${libdir}/libcogl.la \
+                     ${libdir}/pkgconfig/cogl-1.0.pc \
+                     ${libdir}/pkgconfig/cogl-2.0-experimental.pc \
+                     ${libdir}/pkgconfig/cogl-gl-1.0.pc"
+FILES_libcogl-gles2 = "${libdir}/libcogl-gles2${SOLIBS}"
+FILES_libcogl-gles2-dev = "${includedir}/cogl/cogl-gles2 \
+                           ${libdir}/libcogl-gles2${SOLIBSDEV} \
+                           ${libdir}/libcogl-gles2.la \
+                           ${libdir}/pkgconfig/cogl-gles2-experimental.pc"
+FILES_libcogl-pango = "${libdir}/libcogl-pango${SOLIBS}"
+FILES_libcogl-pango-dev = "${includedir}/cogl/cogl-pango \
+                           ${libdir}/libcogl-pango${SOLIBSDEV} \
+                           ${libdir}/libcogl-pango.la \
+                           ${libdir}/pkgconfig/cogl-pango-1.0.pc"
+
+# For backwards compatibility after Debian-renaming
+RPROVIDES_libcogl = "cogl-1.0"
+RCONFLICTS_libcogl = "cogl-1.0"
+RREPLACES_libcogl = "cogl-1.0"
-- 
1.8.1.2

[PATCH 2/3] cogl-1.0: make building cogl-pango optional

[Andreas Oberritter]

Add a 'cogl-pango' PACKAGECONFIG option and enable it by default.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/recipes-graphics/cogl/cogl-1.0.inc | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc b/meta/recipes-graphics/cogl/cogl-1.0.inc
index 8400668..c0d410e 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -8,7 +8,7 @@ SRC_URI += "file://cogl_fixed_mul-constraint.patch \
 
 inherit clutter
 
-DEPENDS = "pango glib-2.0 gdk-pixbuf"
+DEPENDS = "glib-2.0 gdk-pixbuf"
 PACKAGES =+ "${PN}-examples \
              libcogl libcogl-dev \
              libcogl-gles2 libcogl-gles2-dev \
@@ -34,6 +34,8 @@ EXTRA_OECONF += "--disable-introspection	\
 	       	 --disable-gles1		\
 	    	"
 
+PACKAGECONFIG[cogl-pango] = "--enable-cogl-pango,--disable-cogl-pango,pango"
+
 # GL flavours
 PACKAGECONFIG[gl] = "--enable-gl,--disable-gl,${EDEPENDS_GL},${ERDEPENDS_GL}"
 PACKAGECONFIG[gles2] = "--enable-gles2,--disable-gles2,${EDEPENDS_GLES2}, ${ERDEPENDS_GLES2}"
@@ -52,7 +54,7 @@ PACKAGECONFIG[wayland-server] = "--enable-wayland-egl-server,--disable-wayland-e
 
 # Respect the DISTRO_FEATURES to pull in GLX or Wayland as appropriate by
 # default.
-PACKAGECONFIG ??= "gl \
+PACKAGECONFIG ??= "cogl-pango gl \
                    ${@base_contains('DISTRO_FEATURES', 'wayland', 'egl-wayland', '', d)} \
                    ${@base_contains('DISTRO_FEATURES', 'x11', 'glx', '', d)}"
 
-- 
1.8.1.2

[PATCH 3/3] cogl-1.0: add option to enable GLES1

[Andreas Oberritter]

Only PACKAGECONFIG options for GL and GLES2 were available before.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/recipes-graphics/cogl/cogl-1.0.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc b/meta/recipes-graphics/cogl/cogl-1.0.inc
index c0d410e..f2c1e26 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -17,6 +17,7 @@ AUTOTOOLS_AUXDIR = "${S}/build"
 
 # Extra DEPENDS for PACKAGECONFIG
 EDEPENDS_GL = "virtual/libgl libdrm"
+EDEPENDS_GLES1 = "virtual/libgles1"
 EDEPENDS_GLES2 = "virtual/libgles2"
 EDEPENDS_KMS = "libdrm virtual/egl"
 EDEPENDS_EGL = "virtual/egl"
@@ -26,6 +27,7 @@ EDEPENDS_WAYLAND = "wayland"
 # Extra RDEPENDS for PACKAGECONFIG
 # This has to be explictly listed, because cogl dlopens the backends
 ERDEPENDS_GL    = "libgl"
+ERDEPENDS_GLES1 = "libgles1"
 ERDEPENDS_GLES2 = "libgles2"
 
 EXTRA_OECONF += "--disable-introspection	\
@@ -38,6 +40,7 @@ PACKAGECONFIG[cogl-pango] = "--enable-cogl-pango,--disable-cogl-pango,pango"
 
 # GL flavours
 PACKAGECONFIG[gl] = "--enable-gl,--disable-gl,${EDEPENDS_GL},${ERDEPENDS_GL}"
+PACKAGECONFIG[gles1] = "--enable-gles1,--disable-gles1,${EDEPENDS_GLES1}, ${ERDEPENDS_GLES1}"
 PACKAGECONFIG[gles2] = "--enable-gles2,--disable-gles2,${EDEPENDS_GLES2}, ${ERDEPENDS_GLES2}"
 
 # EGL backends
-- 
1.8.1.2

Re: [PATCH 3/3] cogl-1.0: add option to enable GLES1

[Burton, Ross]

On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
> Only PACKAGECONFIG options for GL and GLES2 were available before.

The rationale behind this was that the GLES1 support isn't tested,
mainly as there's not a lot of hardware that can't also do GLESv2.
Was this enabled for completeness or are you actually restricted to
GLESv1?

Ross

Re: [PATCH 2/3] cogl-1.0: make building cogl-pango optional

[Burton, Ross]

On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
> Add a 'cogl-pango' PACKAGECONFIG option and enable it by default.

Really picky, but can we call this just "pango"?

Ross

Re: [PATCH 2/3] cogl-1.0: make building cogl-pango optional

[Tomas Frydrych]

On 11/07/13 09:56, Burton, Ross wrote:
> On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
>> Add a 'cogl-pango' PACKAGECONFIG option and enable it by default.
> 
> Really picky, but can we call this just "pango"?

+1 for that; otherwise, these patches makes good sense to me.

Tomas

-- 
http://sleepfive.com

Re: [PATCH 3/3] cogl-1.0: add option to enable GLES1

[Andreas Oberritter]

On 11.07.2013 10:52, Burton, Ross wrote:
> On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
>> Only PACKAGECONFIG options for GL and GLES2 were available before.
> 
> The rationale behind this was that the GLES1 support isn't tested,
> mainly as there's not a lot of hardware that can't also do GLESv2.
> Was this enabled for completeness or are you actually restricted to
> GLESv1?

It's for completeness, so if you have libraries for both GLES1 and
GLES2, you can compare them easily and then choose the one that works
better for your application. If nothing else, then this may improve test
coverage. Because it's disabled by default, introducing this option
doesn't have any bad side effects. On the good side, it explicitly
disables GLES1, so if a later version of cogl switches to
auto-detection, the behaviour of the build won't change.

Regards,
Andreas

Re: [PATCH 2/3] cogl-1.0: make building cogl-pango optional

[Andreas Oberritter]

On 11.07.2013 10:56, Burton, Ross wrote:
> On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
>> Add a 'cogl-pango' PACKAGECONFIG option and enable it by default.
> 
> Really picky, but can we call this just "pango"?

I prefer cogl-pango, because I think it's more useful to derive the name
from the configure option rather than from the dependency. This way it
won't conflict with a future option --enable-pango or
--enable-something-else-which-depends-on-pango. If you look at
--enable-gles2 vs. --enable-cogl-gles2, this just seems to be the right
thing to do.

Regards,
Andreas

Re: [PATCH 3/3] cogl-1.0: add option to enable GLES1

[Burton, Ross]

On 11 July 2013 11:53, Andreas Oberritter <obi@opendreambox.org> wrote:
>> The rationale behind this was that the GLES1 support isn't tested,
>> mainly as there's not a lot of hardware that can't also do GLESv2.
>> Was this enabled for completeness or are you actually restricted to
>> GLESv1?
>
> It's for completeness, so if you have libraries for both GLES1 and
> GLES2, you can compare them easily and then choose the one that works
> better for your application. If nothing else, then this may improve test
> coverage. Because it's disabled by default, introducing this option
> doesn't have any bad side effects. On the good side, it explicitly
> disables GLES1, so if a later version of cogl switches to
> auto-detection, the behaviour of the build won't change.

The GLESv2 backend will work best, because the v1 backend is crippled
by v1's limitations and lack of testing.  And GLESv1 is already
disabled explicitly in EXTRA_OECONF (that this patch should remove).

I'm leaning towards rejecting this as it doesn't serve a purpose,
unless someone can say that they're actually using the GLESv1 backend
(that upstream admits isn't tested).

Ross

Re: [PATCH 3/3] cogl-1.0: add option to enable GLES1

[Phil Blundell]

On Thu, 2013-07-11 at 12:53 +0200, Andreas Oberritter wrote:
> On 11.07.2013 10:52, Burton, Ross wrote:
> > On 11 July 2013 01:56, Andreas Oberritter <obi@opendreambox.org> wrote:
> >> Only PACKAGECONFIG options for GL and GLES2 were available before.
> > 
> > The rationale behind this was that the GLES1 support isn't tested,
> > mainly as there's not a lot of hardware that can't also do GLESv2.
> > Was this enabled for completeness or are you actually restricted to
> > GLESv1?
> 
> It's for completeness, so if you have libraries for both GLES1 and
> GLES2, you can compare them easily and then choose the one that works
> better for your application. 

If your hardware supports GLESv2 then it seems very unlikely that the
GLESv1 backend is going to work better for any application.  I suppose
it's just about conceivable that there might be some or other bug in the
GLESv2 driver which you could work around by using the GLESv1 API, but
I've never heard of this happening in practice and it doesn't sound very
likely.

I wouldn't be surprised if Cogl's GLESv1 backend went away altogether in
the not-too-distant future.  The gap in capabilities between GLESv1 and
either GLESv2 or big GL is quite significant.

All that said, if there is genuine (even if possibly misguided) interest
in experimenting with GLESv1 then I don't have any real objection to
adding a PACKAGECONFIG option for it.

p.