This is meant as an architecture discussion as there seems to be two different approaches dealing with GLESv2/EGL and GL within the Trunk project. The premise of the discussion is to agree on the way forward so package maintainers can refer to this discussion when making applications/libraries packaging that can deal with both GL and GLESv2 APIs.
On IA, there is a default of building towards GL. On ARM, we build towards GLESv2 + EGL apis as GL on ARM is pretty much non-existent. On IA, we can build against Mesa+headers as it provides a GL API that can be replaced with other libGL.so.1 implementations. On ARM, we're not this lucky to have this, so we have a open source library, libgles-qemu + headers for GLESv2 and EGL providing same functionality. This provides libgles2-devel and libegl-devel and is an implementation for GLESv2 on QEMU/ARM. Current practices seem to be: When depending on GL, BuildRequires: pkgconfig(gl), resulting in a dependancy of libGL.so.1 When depending on GLESv2+EGL: BuildRequires: libgles2-devel libegl-devel, resulting in a dependancy of libGLESv2.so and libEGL.so (this might have to be fixed to be .so.1) On a target, for GLESv2+EGL we can then replace with the actual target device libGLESv2.so and libEGL.so by providing these libraries. Applications then automatically use these on the target. An example is for instance SGX libraries, which we can then use instead on a target and that same built Qt library can be used against several GLESv2 implementations on different devices. However, there has been an introduction lately with mesa-libEGL(-devel), due to handset requirement (mentioned in changelogs), which was also added as build dependancy in some packaging. This then fails when built against for instance a Qt is build against 'our' approach of libgles2-devel and libegl-devel. The question is then what role mesa-libEGL-devel is supposed to have as it does not provide both EGL and GLESv2. Another issue is how to deal with GL/GLESv2 dependancies for Qt-based libraries and applications which also does GL/GLESv2 calls. Currently, there is a tendancy of depending on pkgconfig(gl) when we already are depending on pkgconfig(QtOpenGL). This typically breaks ARM builds which would work just fine due to the QtOpenGL dependancy pulling in the right GL or GLESv2 libraries + headers. And then using GLES2 or GL headers depending on Qt configuration. My suggestion is to only depend on QtOpenGL for those kind of scenarios. The question is then if we should be: * Scrapping the mesa-libEGL-devel package in Trunk and depend on libgles2-devel + libegl-devel in packages instead or * Dropping libegl-devel package from libgles-qemu and depend on mesa-libEGL-devel + libgles2-devel in packages instead or * some third solution? - we don't have enough information to make this choice, as there might be more reasons for mesa-libEGL-devel than we immediately see, hence this question :) Regards, Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
