Hi all, I (as a member of the linaro[1] team) have been trying to integrate the Clutter library in the linaro platform. This entails creating and maintaining packages for both the GLX and EGLX (ES 1.1 and 2.0) flavours of the Clutter library. Of course it is expected that the packages can coexist harmoniously in the archive.
My understanding so far is this: Clutter can be built using different flavours (glx, eglx, win32...) each of which produces a library with a different SONAME. Each flavour provides a small set of API functions that differ from other flavours and therefore flavours are not API/ABI compatible (hence the different SONAME). This leads to the unfortunate situation that all packages that depend on Clutter have to be built and packaged twice: once against the GLX flavour and once against the EGLX flavour of Clutter. This is true even for programs that don't use any of the flavour specific functions and presents a huge overhead for distributions. Another issue is that development files (eg headers) and gobject introspection files (.typelib) are not parallel installable for the different flavours. This makes it very difficult for different flavours to coexist and for build systems to select the one they need. To remedy the issues I have come up with the following suggestions: 1. Create a libclutter library (and relevant introspection info) that contains only API shared across all flavours. Make it possible for this library to include either dynamically (with plugins) or statically (at build time) a subset (or all) of the backends. Provide a mechanism to select the used backend at runtime (command line argument parsed by clutter_init(), an environment variable, a configuration file). 2. Place the flavour-specific API (and relevant introspection info) in separate libraries that can be optionally used only by programs that need them. I understand that these are pretty radical changes but I believe that they considerably ease the packaging and deployment of the Clutter library. I would like to hear your opinions on these suggestions (are they sane and feasible?) and also any alternative approaches you may have in mind. Thanks, Alexandros [1] www.linaro.org -- To unsubscribe send a mail to [email protected]
