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.

Gimp-developer mailing list

Reply via email to