Page MenuHome GnuPG

pkg-config support
Closed, ResolvedPublic

Description

There is a pkg-config file in SVN, but nothing is done with it. I've attached a
patch based on
http://www.nabble.com/pkg-config-support-for-libgcrypt-td8910856.html for proper
support.

I require pkg-config support in order to write bindings for Vala (
http://live.gnome.org/Vala )

Details

Version
1.4.0

Related Objects

Event Timeline

It was accidently left in the SVN. I remove it.

2005-06-25 Moritz Schulte <moritz@g10code.com>

  • Makefile.am (pkgconfigdir, pkgconfig_DATA): Removed variables.
  • libgcrypt.pc.in: Removed file - we do not want to support a

second, foreign configuration system.

In addition to the extra build dependency it creates, pkg-config does not work
well for cross-compiling. A way to detect an incompatible API change is also
not included. pkg-config might be good for packages anydepending on a large set
of libraries and which are all similar, like GNOME or KDE. For a stand alone
non-Linux specific library it does not make too much sense.

For your binding please use the documented way or make use of the vers file.

Assuming you're talking about an extra dependency for building gcrypt, it would
be easy to build and install the *.pc without using the autoconf macros that
come with pkg-config. That said, everyone has pkg-config these days--apparently
gcrypt had a build-dependency on it and nobody even noticed (IIRC it was being
build, just not installed)? That's a decent indicator that nobody would mind, IMHO.

As for cross-compiling, I don't have much experience. That said, pkg-config
support could exist in parallel to the existing stuff, and people wouldn't have
to use it.

API breaks are usually handled with the package name. For example, glib-2.0,
gtk+-2.0, etc. I can also thing of a couple of API breaks for minor releases
that were handled quite easily--gstreamer-*-0.8 -> gstreamer-*-0.10 and
libsoup-2.2 -> libsoup-2.4. Naming the file gcrypt-1.0.pc would be quice
appropriate, or if your API breaks at minor releases, gcrypt-1.4. Or gcrypt.pc
and a future version could be gcrypt-2.0.pc.

pkg-config may not be perfect, but really it's the only thing that even comes
close to a standard way of doing what it does. Vala requires a pkg-config file,
so without one I can't create bindings.

Finally, "supporting a second, foreign configuration system". Autoconf does all
the real work, and the only time you should ever have to touch the pkg-config
file is for an API break as discussed above, and even then all you have to do is
change the file name. I know it's something of an empty promise since you don't
know me, but I can take care of any maintenance related to pkg-config support
for the foreseeable future.

nemequ renamed this task from pkg-config support broken to pkg-config support.Apr 23 2008, 7:45 PM
nemequ reopened this task as Open.
nemequ lowered the priority of this task from Normal to Wishlist.

We have never used pkg-config. That there has never been a build dependecy on it.

We won't maintain a .pc file in addition to gcrypt-config. That does not make
any sense.

Regarding API breaks: Changing the name of the .pc file does not help. You
wouild need to change the autoconf macros of all packages using that library -
that is not possible. Except of course if you change the name of the header
file - that is something I don't like.

If some extra output from libgcrypt-config is helpful for you, just let me know
and it will be added. But please use the mailing list for such a discussion.

werner claimed this task.