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

Alon Bar-Lev alon.barlev at gmail.com
Tue Dec 4 02:46:19 CET 2018

On Tue, Dec 4, 2018 at 2:54 AM NIIBE Yutaka <gniibe at fsij.org> wrote:
> Hello,
> Please accept my apologize if tone of my writing sounded too strong.
> Perhaps, I (wrongly) recognized that my efforts were disregarded.

Your efforts are not disregarded and are appreciated, 3rd party
components long waited for having pkg-config support for gnupg
components, now you have provided that, which is the base of taking
this farther into the gnupg build itself.

Based on your detailed description it seems like you do not understand
that us, downstream maintainers, and us, developers, need to cope with
a complex proprietary build system. I truly understand your point of
view, however, the larger picture is that we have many packages to
maintain in different scenarios and combinations, and gnupg build
system just make it harder to create a solution with no actual
functional benefit other than saying the pkg-config is not the idle
solution out there.

You truly believe that the build system of gnupg was simplified with
recent effort and you are probably right... however, this is not
enough when looking at the greater picture as it requires special
attention and does not comply with the best practices of build system
that we have worked so hard to reach.

Any proprietary build system, as simple as you may believe it is
introduce additional complexity in the grand plan. In this discussion,
I am not interested in taking anything from you, we can continue to
build and maintain gnupg packages without pkg-config, however, I would
like you to allow the option for downstream and developers who wishes
to use pkg-config to do so, this is a trivial effort to maintain now
that you provide pkg-config metadata.

Once again, I would like to see gnupg build system make both of us
happy, by default use your best/simplest/efficient build system, and
in addition provide pkg-config alternative for users who wishes to use
this method. It is trivial to support that, as I've shown in this

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

Let's summarize what I understand so far:

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

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.


More information about the Gnupg-devel mailing list