NIIBE Yutaka gniibe at
Fri Jul 13 07:22:15 CEST 2018


I'd like to adopt pkg-config methodology to GnuPG.  I mean,
providing PACKAGE.pc.

I know that we had discussions in the past.

Since then, situation has been changed; pkg-config 0.27 and later allow
--with-internal-glib option at configure time.  We also have pkgconf
now.  I think that our concern about dependency to another software is
smaller now.

So, I think that we can move now.

For GnuPG configure, we now have following:


Using those *-config works, but I think that using pkg-config is better.
At least, using pkg-config which supports multiple libraries at once,
linking can be simplified and accurate.

Today, I have a specific problem.

These days, libgpg-error is used by many (ksba, assuan, gcrypt, ntbtls,
and GnuPG itself).   Now, using each *-config, GnuPG's linking has
many -lgpg-error.

It is only redundant, for normal case, that's true.

But for a developer, who installs development version of libgpg-error in
/usr/local (and still keep using old libgpg-erro in system), he may
encounter a problem, say, if he still uses old ksba package.

That's because... while ksba-config --libs returns (for example)

	-L/usr/lib/x86_64-linux-gnu -lksba -lgpg-error

new gpg-error-config --libs returns

	-L/usr/local/lib -lgpg-error

Then, appending those to generate the executable kbxutil in gnugp/kbx,
old libgpg-error is selected, unfortunately.

I think that now is a good opportunity to move on.

Any thoughts?

More information about the Gnupg-devel mailing list