Page MenuHome GnuPG

pkg-config support for gpgme
Closed, ResolvedPublic


Applications which use GPGME currently need to use AM_PATH_GPGME for detecting gpgme's presence. However, when
running the script from a source repository, this macro is missing if GPGME is not present, causing
autoconf itself to fail (even if GPGME support is eventually optional in the configure script).

A workaround is to bundle the AM_PATH_GPGME macro in the project VCS, but this is ugly and hackish.

GPGME should instead provide a .pc file so applications can use PKG_CHECK_MODULES for checking (and be integrated
into other build systems besides Autotools, such as CMake which has pkg-config support).


git master

Related Objects

Event Timeline

hyperair set Version to git master.
hyperair added a subscriber: hyperair.

I don't understand what you mean. gpgme.m4 gets installed my gpgme and thus the
AM_PATH_GPGME macro is available. There will be no pkg-config support, becuase
cusom config files are more flexible.

Okay, I now see what you mean. is a mainatiner tool and not a distribution. If your application
uses gpgme, I suggest to distribute the gpgme.m4 in the m4 directory.

That's the current approach I'm using, but like I said in the first message, it
feels ugly and hackish.

Exactly what do you mean by custom config files being more flexible, anyway? I
don't see anything AM_PATH_GPGME does that can't be done by PKG_CHECK_MODULES as
long as you ship a .pc file.

Please note that I'm not asking that you drop the gpgme-config/AM_PATH_GPGME
method, I'm just asking that you provide the .pc file as an alternative method
for detecting GPGME, because applications that use other build systems such as
CMake cannot make use of autoconf macros.

If you use CMAKE, you need to write your own test. gpgme-config provides all
what you need.

This has been discussed several times, and I don't see a reason to warm up this
discussion again on the BTS.

werner claimed this task.
werner added a project: Won't Fix.

Well, so be it then. I can't say I understand the decision (have you considered those
who don't need that unnecessary flexibility?), but I guess I'll just have to continue
shipping gpgme.m4 within the geany-plugins autofoo buildsys. The waf buildsys will just
have to reimplement the check. I don't look forward to the day that you guys decide to
change gpgme.m4 though, assuming that ever happens.

Actually I recently changed it to detect misconfigured cross-platform build
systems. All the m4 files are chnage from time to time; it is the same as with
libtool or config.guess.