[gnutls-dev] pkg-config file for libgnutls

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

>> Which leads to, on my Debian box:
>
>> jas at mocca:~$ pkg-config --libs gtk+-2.0
>> -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
>> jas at mocca:~$
>
>> Note that even '-lm' and '-lX11' is there.  IIRC, the gtk people
>> invented pkg-config, so they should hopefully use the best practice.
>
> Afaik that is because
> a) gtk *does* expose and require the atk
> (/usr/include/gtk-2.0/gtk/gtkaccessible.h) and cairo
> (/usr/include/gtk-2.0/gdk/gdkcairo.h) APIs/headers

I see your point, but I'm not sure it holds for gtk.  Does gtk, or one
of its dependencies, also expose the -lm, -lX11, -lpango etc APIs?
The 'pkg-config --libs gtk+-2.0' output seem to contain all libraries
use by any gtk application.  That wouldn't be necessary, since both
libgtk and libgdk dynamically links with -lX11, -lpango etc.

Lacking any clear and referencable documentation to answer this, I
think mimicking the GTK people's pkg-config behaviour is the best we
can do.  They wrote pkg-config after all.  That means adding the
'Requires:'.

> and
> b) because Requires.private is currently rather useless
> http://bugs.debian.org/390132 forcing GNOME to use Requires instead.

Ah, maybe fixing that bug is the real solution.  Then gnutls could
have:

Requires.private: libtasn1

and no 'Requires:'.

Maybe we could make this change now, reverting to the old behaviour,
and be prepared for when 'Requires.private' works fine?  As far as I
understand, it does work today, except recursively.

> Yes, when building pkg-config itself it queries libtool to check
> whether indirect dependencies should be reported on the arch it is
> building for. The result is then hardcoded into the pkg-config binary.

Yes, ok, so I now think it should be 'Requires.private: libtasn1'.

>> Anyway, I consider pkg-config a poor design since it doesn't use the
>> test-for-a-feature-approach.
> [...]
>
> I do not disagree. ;-) It is a little bit better still than using a
> separate libfoo-config script. ;-)

Yes.  Although it does require users to install yet another package
(pkg-config)...  to me, that almost, but only almost, cancels out the
advantage.

/Simon