On 8 January 2013 13:38, Andrew Chadwick <a.t.chadw...@gmail.com> wrote: > Thanks for that useful braindump, Jon. Gives me a really good idea of > intent of the lib. > > I've been discussing it on IRC - see the attached log. Advice from the > Debian folks I've spoken to is to not ship a static binary build on > the expectation that other packages will be able to build against it > as part of their own binary builds. In summary, that is problematic > because changes to the lib made by mypaint may require those other > packages to perform additional binary uploads. Runtime support > packages for such static blobs only serve to compound the issue. Such > additional uploads are organizationally fiddly, and technically > unnecessary in comparison to the same lib expressed as a dynamic > library package with a declared ABI level reflected in the SONAME. > > Given the above, I won't be making libmypaint* packages which contain > only a static .a and runtime support for it. > > Given the current ABI instability and lack of docs (and given that I > don't want to be overambitious at first with my packaging!), I > probably won't be making dynamic libmypaint* packages for the 1.1.x > release, and I won't be doing so at first. Ok, sounds fair. Does not surprise me that Debian people would frown at this. :)
> On a strategy note, would it be possible for a future release to > support both of the use-cases you identify by building two dynamic > libraries? One for the minimal core, and one depending on it for the > glib+GI+GEGL brew. It's certainly a lot nicer for Linux distributions > to do it that way, which in turn may help the code gain popularity☺. > Apps which require static linkage would still have the option of > bundling, if that's a more normal thing to do on certain platforms. That is the rough idea. libmypaint is the minimal thing. libmypaint-gegl contains the GEGL backend. They have separate .so and pkg-config files, and paths for header files. GI adds separate .gir and .typelib for each of these libraries. There is one exception though. libmypaint.so will link against glib when built with GI support (and not when built without). As glib is a very common package, I cannot imagine (binary based) Linux distributions to mind this. To consumers of a pre-built package the dependency is not exposed in any way. -- Jon Nordby - www.jonnor.com _______________________________________________ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
