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
On Sun, 18 Jul 2004, Mike Hearn wrote:
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:
Kewl, thanks! I'll add this to the downloads page.
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.
Good deal.
I checked the server logs the other day, there have been ~1700 downloads
Excellent! What I've heard from people who have used this has been positive. I know from my own experience that it can sometimes fail, but I've not heard any complaints either.
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:
I've added a link to the above to the download page.
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! :)
*Grin* I love that autopackage was able to use inkscape for that. :-) Befriend Brisgeek; he is the best icon author I know.
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.
Yeah, I ran into the gtkspell issue last time I installed the autopackage, on SuSE 9.1.
You use it like this:
gcc -o testapp testapp.c -lgtkspell
becomes
gcc -o testapp testapp.c `relaytool --relay gtkspell -lgtkspell`
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.
Sounds like something worth looking at. Note though that long term we intend to implement a more sophistictated plugin extension system, with the intent of providing a systematic way of handling things like gtkspell. So hopefully we won't need this...
By the way, Mike, one request we have for autopackage, that we'd like to see implemented by the time we release 0.40 is a way for us to hook to the autopackage files without having to include them in our source trie. In other words, we'd like to be able to link to a libautopackage that includes prefix.cpp and such, rather than have prefix.cpp inside our codebase. I think this would benefit us by making it a little more straightforward to coordinate changes between our projects. What do you think?
Bryce
On Sat, 17 Jul 2004 18:28:56 -0700, Bryce Harrington wrote:
Excellent! What I've heard from people who have used this has been positive. I know from my own experience that it can sometimes fail, but I've not heard any complaints either.
0.6 fixed a bunch of bugs with unusually set up systems, hopefully you'll have more luck with this release.
*Grin* I love that autopackage was able to use inkscape for that. :-) Befriend Brisgeek; he is the best icon author I know.
Where can I find Brisgeek? I'm sure he can do a better job than that :)
Yeah, I ran into the gtkspell issue last time I installed the autopackage, on SuSE 9.1.
Oops! I thought I had disabled that in the configure script, but it seems some modifications I made were lost at some point. Well it's fixed now.
You use it like this:
gcc -o testapp testapp.c -lgtkspell
becomes
gcc -o testapp testapp.c `relaytool --relay gtkspell -lgtkspell`
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.
Sounds like something worth looking at. Note though that long term we intend to implement a more sophistictated plugin extension system, with the intent of providing a systematic way of handling things like gtkspell. So hopefully we won't need this...
That works too, though obviously not so well for new symbols in pre-existing libs like the new GTK file picker.
By the way, Mike, one request we have for autopackage, that we'd like to see implemented by the time we release 0.40 is a way for us to hook to the autopackage files without having to include them in our source trie. In other words, we'd like to be able to link to a libautopackage that includes prefix.cpp and such, rather than have prefix.cpp inside our codebase. I think this would benefit us by making it a little more straightforward to coordinate changes between our projects. What do you think?
Well, we discussed this when first implementing binreloc and decided that given how different varying codebases were and how small the code was, it made sense to simply copy & paste for now. In future we're hoping to get this functionality into glib (and maybe Qt as well) so it'll be available from there.
thanks -mike
On Sun, 18 Jul 2004, Mike Hearn wrote:
On Sat, 17 Jul 2004 18:28:56 -0700, Bryce Harrington wrote:
Excellent! What I've heard from people who have used this has been positive. I know from my own experience that it can sometimes fail, but I've not heard any complaints either.
0.6 fixed a bunch of bugs with unusually set up systems, hopefully you'll have more luck with this release.
Cool, I'll plan on inflicting it on the folks at work again, and take notes as to how it goes.
*Grin* I love that autopackage was able to use inkscape for that. :-) Befriend Brisgeek; he is the best icon author I know.
Where can I find Brisgeek? I'm sure he can do a better job than that :)
He's the creator of the etiquette icon set (see http://themes.freshmeat.net/projects/etiquetteicons/) He's occasionally on our jabber channel. His email address is andrew at fitzsimon.com.au You can check out his site at http://andy.fitzsimon.com.au and at http://brisgeek.com.
Sounds like something worth looking at. Note though that long term we intend to implement a more sophistictated plugin extension system, with the intent of providing a systematic way of handling things like gtkspell. So hopefully we won't need this...
That works too, though obviously not so well for new symbols in pre-existing libs like the new GTK file picker.
*Nod* Yup, quite true.
By the way, Mike, one request we have for autopackage, that we'd like to see implemented by the time we release 0.40 is a way for us to hook to the autopackage files without having to include them in our source trie. In other words, we'd like to be able to link to a libautopackage that includes prefix.cpp and such, rather than have prefix.cpp inside our codebase. I think this would benefit us by making it a little more straightforward to coordinate changes between our projects. What do you think?
Well, we discussed this when first implementing binreloc and decided that given how different varying codebases were and how small the code was, it made sense to simply copy & paste for now. In future we're hoping to get this functionality into glib (and maybe Qt as well) so it'll be available from there.
That sounds okay for the time being, although we will keep lobbying for it for the future. I think the motivation is less about the code size so much as the fact that it is low level code that is being shared by multiple projects. As well, copy-and-paste codebases tend to work best when the code is static (for instance the ecma code we imported into the inkscape codebase is not likely to change); having it be a separate lib (or part of glib) would enable the autopackage project to update and make changes to the code without having to coordinate with each project that uses it. Incorporating it into glib would provide a similar solution, although note that that may be less flexible than if autopackage maintained a separate lib (for users with old glib's or wishing to use it on *nix's that don't use glib).
Anyway, I'm sure you've gone over all these types of considerations already, but it may be worth thinking some more about. As autopackage's popularity scales up, the copy-and-paste approach for the shared code may make things more challenging for you in future deployments.
Thanks again, Bryce
Bryce Harrington a écrit :
On Sun, 18 Jul 2004, Mike Hearn wrote:
On Sat, 17 Jul 2004 18:28:56 -0700, Bryce Harrington wrote:
Excellent! What I've heard from people who have used this has been positive. I know from my own experience that it can sometimes fail, but I've not heard any complaints either.
0.6 fixed a bunch of bugs with unusually set up systems, hopefully you'll have more luck with this release.
Cool, I'll plan on inflicting it on the folks at work again, and take notes as to how it goes.
*Grin* I love that autopackage was able to use inkscape for that. :-) Befriend Brisgeek; he is the best icon author I know.
Where can I find Brisgeek? I'm sure he can do a better job than that :)
He's the creator of the etiquette icon set (see http://themes.freshmeat.net/projects/etiquetteicons/) He's occasionally on our jabber channel. His email address is andrew at fitzsimon.com.au You can check out his site at http://andy.fitzsimon.com.au and at http://brisgeek.com.
Sounds like something worth looking at. Note though that long term we intend to implement a more sophistictated plugin extension system, with the intent of providing a systematic way of handling things like gtkspell. So hopefully we won't need this...
That works too, though obviously not so well for new symbols in pre-existing libs like the new GTK file picker.
*Nod* Yup, quite true.
By the way, Mike, one request we have for autopackage, that we'd like to see implemented by the time we release 0.40 is a way for us to hook to the autopackage files without having to include them in our source trie. In other words, we'd like to be able to link to a libautopackage that includes prefix.cpp and such, rather than have prefix.cpp inside our codebase. I think this would benefit us by making it a little more straightforward to coordinate changes between our projects. What do you think?
Well, we discussed this when first implementing binreloc and decided that given how different varying codebases were and how small the code was, it made sense to simply copy & paste for now. In future we're hoping to get this functionality into glib (and maybe Qt as well) so it'll be available from there.
That sounds okay for the time being, although we will keep lobbying for it for the future. I think the motivation is less about the code size so much as the fact that it is low level code that is being shared by multiple projects. As well, copy-and-paste codebases tend to work best when the code is static (for instance the ecma code we imported into the inkscape codebase is not likely to change); having it be a separate lib (or part of glib) would enable the autopackage project to update and make changes to the code without having to coordinate with each project that uses it. Incorporating it into glib would provide a similar solution, although note that that may be less flexible than if autopackage maintained a separate lib (for users with old glib's or wishing to use it on *nix's that don't use glib).
Anyway, I'm sure you've gone over all these types of considerations already, but it may be worth thinking some more about. As autopackage's popularity scales up, the copy-and-paste approach for the shared code may make things more challenging for you in future deployments.
Thanks again, Bryce
This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I just encountered today a problem with the new autopackage : tells protocol error.
cedric
On Tue, 20 Jul 2004, cedric wrote:
Bryce Harrington a �crit :
Cool, I'll plan on inflicting it on the folks at work again, and take notes as to how it goes.
I just encountered today a problem with the new autopackage : tells protocol error.
I ran into a similar problem (error: protocol 4/5 mismatch) when installing it for someone at work.
Bryce
On Tue, 2004-07-20 at 09:59 -0700, Bryce Harrington wrote:
I ran into a similar problem (error: protocol 4/5 mismatch) when installing it for someone at work.
That means you have an old copy of some code lying around. It should upgrade it for you but if you installed autopackage from CVS or a release candidate it may not.
Try "package remove autopackage-gtk autopackage", make sure your system doesn't have the package or autopackage-frontend-gtk programs anywhere, then try again.
thanks -mike
participants (3)
-
Bryce Harrington -
cedric -
Mike Hearn