Hi guys,
Firstly, some good news. On compiling Inkscape against the GTK 2.2 headers, which is a part of doing an autopackage release of it, my crash mysteriously vanished. So that's an interesting data point.
Secondly, there is an package of 0.39 available here:
http://navi.cx/~mike/inkscape/0.39/inkscape-0.39.package
It's built against a new version of autopackage, 0.6, which will be released properly sometime tomorrow. Likewise the nightlies and the GTKmm/sigc++ packages have also been rebuilt against that release.
I checked the server logs the other day, there have been ~1700 downloads of the inkscape autopackage. Of those approximately half also pulled in GTKmm as a resolved dependency. We've had very little feedback from this - I had assumed there simply weren't many people using the service, but clearly this is not the case. I guess it's simply working pretty well for people! :)
Because of this I'm feeling pretty confident that the 0.6 release is likewise stable and reasonable compatible with a variety of setups - in fact we've fixed a few distro compatibility bugs in this release, especially for Slackware users. So, if you could link to the 0.39 package from the Inkscape website, that'd be great as I feel a lot of people would benefit from a package of the stable release. Hongli has created some stock HTML that people can embed/tweak for their websites which identify the fact that it's an autopackage and link to the instructions for how to install them:
http://www.autopackage.org/docs/howto-install/index.html
I don't have that right now, but I'd be interested in your opinions on the stock HTML idea later.
Having packaged up Inkscape of course I wanted to play with it - that's where the crash report came from. So I drew an icon/logo for autopackage:
http://autopackage.org/logos/logos.html
Why not marvel at my lack of artistic talent? If any of the pros on this mailing list want to draw us a better one please feel free! :)
Finally, I'm afraid I'm not finished with the patches yet! This:
http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/autopackage/apbuild/relaytool
... is likewise a non-work of art. I was originally going to submit a patch to make gtkspell dlopened at runtime, but realised that this was (a) tedious and (b) going to happen a lot. So I wrote relaytool which is designed to automate it.
For those who haven't read the above URL, relaytool is a program which generates C files you can compile and link into your app, which replaces the -lfoo option you'd normally use with a "soft link". It uses assembly and ELF magic to perform the link at runtime using dlopen, but it won't fail if the library isn't present. The interesting thing about this approach is that it requires no code changes, and doesn't rely on icky stuff like header rewriting. Code like this:
#ifdef HAVE_GTKSPELL gtkspell_attach( ... ) #endif
can simply become:
#ifdef HAVE_GTKSPELL if (libgtkspell_is_present) gtkspell_attach( ... ); #endif
And as long as the binary was compiled in the presence of the gtkspell headers, at runtime Inkscape will use libgtkspell if it's present and continue without spell checking ability if it's not.
Therefore we can cut down on the number of hard dependencies for Inkscape, so increasing the reliability and robustness of the installation.
It works for exported variables too, though not many libraries use that. In theory it also works for C++ objects but I haven't tried it yet.
You use it like this:
gcc -o testapp testapp.c -lgtkspell
becomes
gcc -o testapp testapp.c `relaytool --relay gtkspell -lgtkspell`
And the stub file will be generated and compiled transparently on systems that relaytool supports. On systems it doesn't support the -l option is passed through unchanged.
relaytool isn't quite ready yet, in particular I need to write an autoconf check for ELF platforms so using it doesn't interfere with the build on Windows and MacOS X.
We can use a similar technique to allow Inkscape to use the GTK 2.4 file picker but cleanly fall back to the GTK 2.2/2.0 APIs when GTK 2.4 isn't present.
Hope that helps,
thanks -mike