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

[NIIBE Yutaka]

Hello,

Please accept my apologize if tone of my writing sounded too strong.
Perhaps, I (wrongly) recognized that my efforts were disregarded.

IIUC, you haven't try build of current master of GnuPG, with master of
npth, libgpg-error, libassuan, libgcrypt, libksba, and ntbtls, which
introduced .pc files for pkg-config compatibility.  (Well, it is also
introduced to gpgme.)

I should have assumed that.

Let me explain in detail, even if it's TL;TR...

Or it is better to begin with a short answer, changing the order
of answer.

> Pseudo code per each <library>.m4:
>
> +if enable_pkg_config = yes:
> +   use pkg-config via pkg.m4 macro to detect dependency flags
> [usually oneliner]
> +else:
>     use *-config macro to detect dependency flags
> +endif
>
> Why does this takes anything from the larger picture?

It's OK for <library>'s user to do that, but we don't do that for GnuPG
build.

That's because it is not needed; In the current situation, it just
complicates things while adding no benefit.

Please understand that I don't deny your points what to be achieved by
such a change.  It's done already in a different way, other than
introducing use of pkg-config.

			*	*	*

Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> Please explain again why not give an option for downstream to build
> gnupg components using pkg-config, this does not take anything from
> whoever wishes to continue to use current mode.

For pkg-config compatibility, GnuPG libraries (npth, libgpg-error,
libassuan, libgcrypt, libksba, and ntbtls) introduced .pc files.

And we introduced a single script, named gpgrt-config, to handle .pc
files.  This is a kind of cut-down version of pkg-config.

Now, other *-config scripts are only provided for backward
compatibility.  (It is no use for new way of building GnuPG).

I did so, in order to separate static data (which can be described as
pkg-config style) and running script (which tends to easily introduce
peculiar incompatible things).  I believe that by doing so, we can
maintain libraries of GnuPG, as friendly as possible to pkg-config.

Direct benefit of introducing .pc files are for users of those
libraries, they can use pkg-config for their applications (by "[usually
oneliner]" macro of pkg.m4), if they like.  Instead of use of pkg.m4
macro, still, using old <library>.m4 with <library-specific>-config is
supported, and new <library>.m4 with gpgrt-config or
<library-specific>-config is also supported.

However, we don't use pkg-config for GnuPG build itself to configure
GnuPG libraries, while it uses pkg-config for optional external
libraries (sqlite and GnuTLS).  We do so, because GnuPG should be
build-able without pkg-config.  This is important requirement of GnuPG.

Optionally using pkg-config would make sense, if it doesn't add more
complexity for maintenance of GnuPG and if it can provide some benefit.
But... I think that newly introducing optional use of pkg-config for
GnuPG libraries just adds more unnecessary complexity for GnuPG build,
with no benefit.

While we try to keep the compatibility of pkg-config, the behavior of
pkg-config and gpgrt-config may be different, when pkg-config will
change.  When behaviors are different, this should be fixed soonish, but
it may take longer without being noticed.  When it occurs, the impact
for GnuPG build is... bad enough, since GnuPG will be not reproducible
in these two environments; The build with pkg-config (normal build) and
the build with pkg-config wil be different.


Although it's a side effect (I mean, it was not my own purpose
originally), my effort allows better support of GnuPG cross build in
various situations (multiarch in Debian, multilib for
Arch/Fedora/OpenSUSE, and straight cross build for Windows), just like
pkg-config can offer.

Actually, my effort greatly simplifies the situation of GnuPG cross
build, because we only use a single script.

In case of pkg-config, cross build is not supported by the tool itself,
but it is supported by some arrangement of distribution.  For example,
in case of Debian, we have {HOST_ARCH}-pkg-config which links to
/usr/share/pkg-config-crosswrapper.  This is not ideal situation, yet.

In old ways, there were {HOST_ARCH}-<library-specific>-config scripts
for GnuPG (too many!).  Use of pkg-config can improve the situation to
have {HOST_ARCH}-pkg-config only.  Now, there is only a single script of
gpgrt-config.

Speaking about less possibility thing, when/if we will have pkg-config
implementation (re-)written as portable AWK script, in future, we will
be able to use pkg-config directly.  Then, we will be able to throw away
gpgrt-config.
--