[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-print-devel
Subject:    Re: [Gimp-print-devel] Gimp-Print static/shared library issues
From:       Roger Leigh <rleigh () whinlatter ! ukfsn ! org>
Date:       2004-08-31 19:26:42
Message-ID: 87u0ujp0r1.fsf () whinlatter ! whinlatter ! ukfsn ! org
[Download RAW message or body]

Robert L Krawitz <rlk@alum.mit.edu> writes:

>    Cc: rleigh@whinlatter.ukfsn.org, gimp-print-devel@lists.sourceforge.net
>    From: Roger Leigh <rleigh@whinlatter.ukfsn.org>
>    Date: Wed, 25 Aug 2004 22:46:31 +0100
>
>    Robert L Krawitz <rlk@alum.mit.edu> writes:
>
>    >    From: Roger Leigh <rleigh@whinlatter.ukfsn.org>
>    >    Date: Tue, 24 Aug 2004 23:27:28 +0100
>    >
>    >    While fixing the Debian build, I've found a few problems I'd like to
>    >    fix for the release:
>    >
>
>    For Gimp-Print, the stable packages are "libgimpprint1" and
>    "libgimpprint1-dev", and the development packages are
>    "libgimpprint-VERSION" and "libgimpprint-VERSION-dev".
>
>    With the module system, it's no longer possible to build a shared
>    and a static libgimpprint /at the same time/, due to the different
>    module build and link requirements.  This means to provide a static
>    copy means doing two separate builds during the package build
>    process.  Since the static copy is likely never used, I'm going to
>    drop it.
>
>    The libgimpprintui library is a different case.  When libgimpprint was
>    created, it made sense to package it as a shared library, since it was
>    used by at least gs, cups and the Print plugin, so there were multiple
>    packages depending on it, and potentially others to use it as well.
>    With libgimpprintui, this is not the case: there's only a single user,
>    so there's no need to make it shared.  It's also never going to be
>    used by any other program in its current state, being very
>    GIMP-specific.  Packaging it as a shared library would mean adding two
>    extra packages to the distribution, and since these would be useless
>    (in terms of reusability and adding extra package bloat), it would not
>    provide any advantage over static linking.
>
> The extra packages are because of Debian rules, right?

Partly, but I think other distributors will probably have similar
issues.  I'm not sure if anyone else provides the Print plugin as a
separate package though (as opposed to the one included with the
GIMP).

> I don't want to encode Debian (or any other distribution-specific
> process) rules in our build system.

That's fine.  I don't want to reduce the package's flexibility unless
there's a real need.

>    I'd like to have the option of allowing either a static or shared
>    libgimpprintui.  The problem is that currently it's not possible to
>    build some libraries shared and some static: it's all one or all the
>    other.  This is because --enable-static and --enable-shared act on all
>    libtool-generated libraries.
>
> So let me understand: your intention is to force libgimpprintui to
> always be static, but to allow the user the option for libgimpprint?

Yes.  Unless libgimpprintui has wider utility than just the GIMP Print
plugin, I just don't think it is useful as a shared library right now.

>    >    So if you think it's OK, I'd like to change AC_ENABLE_STATIC to
>    >    AC_DISABLE_SHARED (should not have any practical effect), and change
>    >    libgimpprintui[2] to build static-only .a libraries.
>    >
>    >    If you would prefer to do something else, or leave these changes until
>    >    after the beta2 release, I will leave the Debian changes until after
>    >    the release.
>    >
>    > Is this issue only for Debian, or are there other issues?  I don't
>    > want to lock everyone out of a useful option just for the Debian build
>    > rules.
>
>    They are issues that all distributors/packagers will have to look
>    at, so I don't think they are Debian-specific.  I think we might be
>    stricter with our library packaging policies, though.
>
> SUSE doesn't seem to forbid having multiple shared libraries in one
> package.

Neither does Debian, though it's not very common, and it's not used
much due to creating unnecessary dependencies.  e.g. if libgimpprintui
was packaged with libgimpprint, every libgimpprint-using program would
indirectly depend upon GTK+ (which is not desirable).


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


-------------------------------------------------------
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=5047&alloc_id=10808&op=click
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
[prev in list] [next in list] [prev in thread] [next in thread]