Re: [Mypaint-discuss] Anatomy of brushlib/libmypaint for 1.1.0 (for the Debian packages)
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. 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. -- Andrew Chadwick #debian-mentors Mon 07 Jan 2012 12:10 - 12:39 achadwick Is there an established convention for naming runtime support packages for apps built against a _static-only_ library? Translated strings in my case. I want to name the static dev package libmypaint-dev, so should runtime stuff go in a libmypaint-data or libmypaint-common? achadwick What's the most unsurprising name? I'm pondering using just libmypaint, but that might be confusing because a) upstream intend to support dynamic libs once the ABI is more stable, and reading closer, b) the usecase (and ABI) for dynamic is intended to be fuller, by design. pabs best not distribute the library at all until it becomes dynamic achadwick Why? OdyX or ship a -dev package with everything needed to compile it OdyX achadwick: because we don't want packages to incorporate static libraries components; that's not how Debian is supposed to work. * dpkg has quit (Quit: buh bye!) OdyX achadwick: a possibility would be to patch the thing to have a Debian-specific SONAME (see libjim for example) and go through NEW every time you want a new release. achadwick Yep. I'm intending to ship a -dev package with headers and the .a in question. (Disclaimer: I'm part of upstream, but I don't work on that bit. I support the developer-in-question's use cases and intents development against it.) achadwick *for development OdyX what is the benefit for both Debian and the library upstream developers to have it in Debian ? * dpkg (~d...@dpkg.bot.oftc.net) has joined #debian-mentors achadwick Upstream Gimp, Krita, and Blender have expressed interest in using the engine, and this would be the static linking usecase. It could facilitate development if they didn't have to bundle it into their source and could just rely on external provision of headers and a static lib. For the DDs of the package, the same would hold via build-dependencies. achadwick The libmypaint source (it's a lib for rendering dynamic brush strokes generated with graphics tablets into pixel buffers) is currently part of the mypaint source (a python app which builds its own C++ bits against the C libmypaint, statically; at present) pabs sounds like it would be much more useful for those purposes once the API and ABI is stabilised pabs good to hear about the convergence though, mypaint brush stuff is great OdyX looks like more dynamic linking + ABI stability evangelism is needed. algernon 2 achadwick Dynamic linking will happen, just not by default in this release. It'll be required for the gir view of the lib in its full configuration. That part, I think, is not yet stable enough. achadwick Noting http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static - basically we hit the last couple of bullet points. OdyX achadwick: the problem with static linking is that any update of the library imposes a binNMU of all packages making use of it OdyX and that's anti-distro-ish * pabs would suggest just shipping a dynamic lib from the start and bump ABI every time as usual OdyX yeah, same here. OdyX achadwick: I've done just that for jimtcl - libjim and it's not a too big pain to manage, and has many benefits IMHO. pabs if upstream isn't enabling that yet you can do so and use a Debian-specific SONAME (append d or debian to it) * yann_s|AFK is now known as yann_s * achadwick nods. There's an
Re: [Mypaint-discuss] Anatomy of brushlib/libmypaint for 1.1.0 (for the Debian packages)
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
Re: [Mypaint-discuss] Anatomy of brushlib/libmypaint for 1.1.0 (for the Debian packages)
On 6 January 2013 04:20, Andrew Chadwick a.t.chadw...@gmail.com wrote: I am considering splitting libmypaint out of the Debian packages I'm working on so that authors of other apps can depend on it more conveniently, and so that other packages can depend on just the lib (possibly only at compile time). Can I confirm a few details? Before we go into the details, lets get a few things clear on the higher level. Warning: long braindump. My intent with libmypaint is that it shall be very easy to: 1) Add support for MyPaint brushes in an existing application. A user that wishes to use the same brushes as he does in MyPaint should be able to do this in all other libre graphics software that offers painting. Krita, GIMP, Blender have all expressed interest. 2) Create new applications with excellent painting tools for purposes and visions different from that of MyPaint. Examples include applications for animation, storyboarding, etc. or applications targeting other device form factors like tablets, smartphones. I envision two primary configurations of libmypaint to address this. 'minimal', mainly targeting usecase 1). Static C library whos only dependency is json-c for loading/saving of brushes and libintl/gettext for translated brush settings. Applications can integrate the library by providing a way to store/retrieve tiles by implementing a MyPaintTiledSurface subclass, or may do the rendering themselves by implementing a MyPaintSurface subclass. A reference surface implementation backed by a fixed size linear buffer is provided as an example. 'full', mainly targeting usecase 2). Provide everything that 'minimal' does. Also provide a reference, production quality, surface backend based on GEGL. Uses GObject Introspection to access from any language supported by GI (Python, Vala, Javascript, ++). Can for instance be used together with gegl-gtk or gegl-qt libraries to enable basic painting applications in less than 200 lines of code. Status as of MyPaint 1.1 * All of the functionality described above is present. * 'minimal' is built by default. To build 'full' use scons enable_gegl=true enable_introspection=true * Both configurations are build by Jenkins. * There will be bugs. Particularly the functionality that is not used by MyPaint is not well tested. * No ABI/API promise. As others attempt to use the library, it may be that we need to adapt the interfaces. * How brushes can be shared between different applications has not been thought out. * Documentation is basically non-existent. For these reason I'd say that libmypaint is currently 'unstable'. I hope that by MyPaint 1.2 these things will be ironed out, but this will require other applications to pick up the library and give feedback. I would like people to do this by just bundle libmypaint with their application, as this makes it easy to use another version that the one released with MyPaint 1.1. But as the GNU/Linux world typically does not do/like bundling, I guess we need to accommodate use through distributions as well. So thanks for bringing that up, and now what you actually asked for. * Can I assume that the version number is the same as that of MyPaint? Yes, as long as they are released together. * Can I also assume that libmypaint is always built correctly as part of a normal MyPaint build (looks like I can)? Yes. MyPaint relies on it and shall use it in much the same way as any other consumer of it would. * Is it the authors' intent that only a static library, libmypaint.a, is available for 1.1.0? I am assuming this is the case. Yes. If you want something else, bundle. * Should the package name be libmypaint, or libmypaint-brushlib? I prefer the 'libmypaint' name. Debian policy will probably also have an opinion about this. * I am assuming that brushlib will be moving to a dynamic library soon in order to support GI-style introspection. Yes, I hope that the build provided by MyPaint will be the 'full' configuration for 1.2 as we move to use GEGL and PyGI/GTK+3. Other than the brushes (which I intend to package separately because the mypaint app uses them too), the following files are installed by a brushlib_only=yes build. That's a good starting point for thinking about this division. I intend to package the files as follows: PREFIX/include/libmypaint/mypaint-tiled-surface.h PREFIX/include/libmypaint/mypaint-brush.h PREFIX/include/libmypaint/mypaint-glib-compat.h PREFIX/include/libmypaint/mypaint-surface.h PREFIX/include/libmypaint/mypaint-config.h PREFIX/include/libmypaint/glib/mypaint-brush.h PREFIX/include/libmypaint/mypaint-brush-settings-gen.h PREFIX/include/libmypaint/mypaint-brush-settings.h PREFIX/include/libmypaint/mypaint-fixed-tiled-surface.h Headers for the static libmypaint.a, and only that, I assume. I'll bundle the entirety of PREFIX/include/libmypaint/** as part of a libmypaint[-brushlib]-dev package. ACK. The header in glib/ subdir should maybe not be installed when not building with
[Mypaint-discuss] Anatomy of brushlib/libmypaint for 1.1.0 (for the Debian packages)
I am considering splitting libmypaint out of the Debian packages I'm working on so that authors of other apps can depend on it more conveniently, and so that other packages can depend on just the lib (possibly only at compile time). Can I confirm a few details? * Can I assume that the version number is the same as that of MyPaint? * Can I also assume that libmypaint is always built correctly as part of a normal MyPaint build (looks like I can)? * Is it the authors' intent that only a static library, libmypaint.a, is available for 1.1.0? I am assuming this is the case. * Should the package name be libmypaint, or libmypaint-brushlib? * I am assuming that brushlib will be moving to a dynamic library soon in order to support GI-style introspection. Other than the brushes (which I intend to package separately because the mypaint app uses them too), the following files are installed by a brushlib_only=yes build. That's a good starting point for thinking about this division. I intend to package the files as follows: PREFIX/include/libmypaint/mypaint-tiled-surface.h PREFIX/include/libmypaint/mypaint-brush.h PREFIX/include/libmypaint/mypaint-glib-compat.h PREFIX/include/libmypaint/mypaint-surface.h PREFIX/include/libmypaint/mypaint-config.h PREFIX/include/libmypaint/glib/mypaint-brush.h PREFIX/include/libmypaint/mypaint-brush-settings-gen.h PREFIX/include/libmypaint/mypaint-brush-settings.h PREFIX/include/libmypaint/mypaint-fixed-tiled-surface.h Headers for the static libmypaint.a, and only that, I assume. I'll bundle the entirety of PREFIX/include/libmypaint/** as part of a libmypaint[-brushlib]-dev package. PREFIX/share/mypaint/brushlib/__init__.py PREFIX/share/mypaint/brushlib/brushsettings.json PREFIX/share/mypaint/brushlib/brushsettings.py JSON definitions of the brush settings; a runtime requirement for using libmypaint, and a Python interface to it. Both could be used by apps other than MyPaint. I intend to package these and the .mo files below as libmypaint[-brushlib], describing it as an architecture-specific requirement for programs statically linked with libmypaint. Hope that's right. PREFIX/share/mypaint/brushlib/generate.py This file appears to be here in error, and I'll probably be removing it from the packages. It's used at compile time for constructing the -gen.h files, and that's it. If I understand recent changes in master correctly, it's being replaced by a scons Command. PREFIX/share/locale/fr/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/id/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ru/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/pt_BR/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/nn_NO/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ro/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/en_CA/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/pl/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/it/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/cs/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ja/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/zh_TW/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/zh_CN/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/sl/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ko/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/uk/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/de/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/hu/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/sv/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/nb/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/es/LC_MESSAGES/libmypaint.mo As described above: runtime requirements, packaged with the JSON stuff. GNU message catalogs appear to be endian-specific, so libmypaint[-brushlib] will be marked as architecture-specific for this reason and in expectation of a .so version, and whatever gir magic is needed. PREFIX/lib/pkgconfig/libmypaint.pc PREFIX/lib/libmypaint.a Compile-time requirement for programs statically linked with libmypaint[-brushlib], part of the -dev package. -- Andrew Chadwick ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
