On Saturday, 17 Feb 2001, Robert L Krawitz wrote: > This raises questions of how to package it with the > Gimp. The Gimp could certainly distribute the whole package with it, > but it's quite large. It could also be treated like JPEG and only > built if the underlying libgimpprint exists on the system. > Suggestions? I'm not convinced that treating it like JPEG is a good idea, because the library is not (yet) as widely spread as libjpeg is. Even today, I sometimes have to fight quite hard to get jpeg or tiff plugins to build for strange architectures. Doing the same for the print plugin would mean that fewer people build and install it, which would be a shame, since it provides some very useful functionality. I think the easiest thing is to have the version in CVS (and gimp snapshots) to include the code for the shared library, and an integrated build system. I'd even go so far to say that the plugin should be statically linked against the library, to avoid version skew if the user installs a different version of the shlib later. Also, the shared library should be available (on sourceforge?) separately packaged for the CUPS, ghostview etc people. Distributions like Debian etc can then put the library in its own package and do their own dependency thing, but we don't have that luxury, I'm afraid. Austin
