[PATCH Libgpg-error] gpg-error.m4: support pkg-config

[NIIBE Yutaka]

Hello,

I think that I should explain from my viewpoint, not as an answer.

So, I'm writing this message for people who build GnuPG.  As an
appendix, I will write an answer to reply, but that's not important
part.


Here we go.

In master branch, we did major improvement to introduce new method,
keeping old method.  We are sorry to say that we don't accept further
change of old method.  We keep old method unchanged (as bad as is).
Please use new method for new features.


(1) We introduce .pc files for GnuPG libraries (npth, libgpg-error,
libgcrypt, libassuan, libksba, and ntbtls) and for GPGME.  


(2) We introduce new gpgrt-config script which is a portable script to
use .pc file for each ${HOST}.  Since it supports all ${HOST} by a
single script, there will be no ${HOST}-gpgrt-config scripts, like
pkg-config (or <library-specific>-config) does in distribution
arrangement.


(3) We introduce new method which uses gpgrt-config script by updated
<library-specific>.m4.  It's up to library users to prefer this m4 with
gpgrt-config, or to prefer pkg.m4 with pkg-config.

Still updated <library-specific>.m4 keeps old method of using
<library-specific>-config script (possibly wrong for some use cases, I
know), but we intentionally keep it for backward compatibility.


(4) For use of updated <library-specific>.m4 for new GnuPG libraries
which come with .pc files, since gpgrt-config script can be used, any
<library-specific>-config script (including
${HOST}-<library-specific>-config scripts) are not needed any more.
Obviously, for use of pkg.m4, <library-specific>-config script is no
need.

Distributions are suggested not to install <library-specific>-config, if
all software will be updated to use updated <library-specific>.m4, or
pkg.m4.

We keep distributing <library-specific>-config for a while, since old
<library-specific>.m4 can be supported.


(5) GnuPG build uses new <library-specific>.m4 with gpgrt-config.  It
does require only a single gpgrt-config for all ${HOST}s for cross
build.  No ${HOST}-gpgrt-config, no <library-specific>-config,
no ${HOST}-<library-specific>-config are required.

With .pc files which are handled by single gpgrt-config script, GnuPG
build has been improved, supporting many cross build cases (multiarch,
multilib in Arch/Fedora/OpenSUSE style, mingw for Windows).

No need of SYSROOT environment variable, no need of
--with-<library-specific>-prefix argument for configure, just run
simple configure with relevant --host=${HOST} (and --libdir for
multiarch).

Please test and enjoy new improvement, and please report problems
of new features.

		*	*	*
An appendix:

Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> Regardless of using pkg-config, in this thread I also showed you that
> your usage of config script is incorrect as:
> 1. AC_CHECK_TOOL should be use to check platform specific tools.
> 2. The config scripts must be prefixed with ${HOST}

This claim is only valid to old code, not correct any more.

In new method, <library-specific>-config was gone, gpgrt-config is only
a single script which is portable, and we don't have
${HOST}-gpgrt-config script.  So, AC_CHECK_PROG is enough.

> 3. The config scripts should have their own target directory, probably
> outside of ${ROOT} as executing anything from ${ROOT} is incompatible
> with cross-compile.

I think that you meant SYSROOT environment variable support.  I know
it's a peculiar method (and possibly strange and wrong in some use
cases).  It's only for specific cross build for Windows.  We don't touch
this existing method.  New users don't need to use this old method.

> 1. You should use the method of detecting and installing config
> scripts to comply with autoconf patterns, this applies to the current
> proprietary solution.

I understand your claim (and partly share your frustrations), which was
valid for old method.

It is somehow compilicated, but we also support old (in some cases,
wrong way) of detecting <library-specific>-config script, to support
existing build and existing software.  We are conservative about that,
we don't have any idea to "fix" this part to comply "correct" autoconf
patterns.

And it is true that we still use gpgrt-config script for GnuPG build
(instead of pkg-config), but this is a single script with no ${HOST}
variants.

> 2. You did not answer the request of supporting both options of using
> the gpgrt-config as default and allow people to use pkg-config if they
> like, this will solve many of the problem other people are
> experiencing and allow downstream maintainer to have predictable build
> behavior if they so choose.

I have explained the reason why GnuPG build never use pkg-config for its
detection of GnuPG libraries.  It's no need, no benefit, but comes with
possible risk.

Nevertheless, many of problems were solved in new method, just like
pkg-config can be achieved.

It's unfortunate, for some people, it hasn't achieved to the status of
complete victory (of using pkg-config for all) yet.  Please don't
complain about that.  As I suggested, when pkg-config will be evolved to
meet GnuPG build requirement, situation will be able to be improved.
Let's see, but, it's not now.
--