Obvious benefit will be:

• It will be easier for developers who use pkg-config for their applications, and want to use gpgme. They can use pkg-config for gpgme.

In gniibe/pkg-config-support branch of libgpg-error, I put my attempt to the improvement.
Now, gpg-error-config is a shell script which uses gpg-error.pc.
This way, we can avoid to introduce more of our local incompatible change against pkg-config, keeping pkg-config style easier.
Now, we have incompatible things: --mt and --host, I'd like to encourage to switch to new compatible use of --variable=mtlibs, --variable=mtcflags, and --variable=host.

Currently, our gpg-error-config is not yet powerful enough to replace existing *-config of ours.
We need to support dependency of modules (recursive reading of *.pc file), and possibly to support multiple modules by a single invocation.

Up to rEe0aecec6d040: Remove AC_CONFIG_COMMANDS for gpg-error-config., now it supports dependency of modules and multiple modules.
A single shell script can be same content (but only names differ).
It only supports features used by our *-config command, though. (Not support --static yet, for example)

Today, I wrote a script:

This is for learning version comparison in the RPM way (== pkg-config way).

If this is correct, we can modify our gpg-error-config to support version constraints.

I found that the version comparison is too difficult, even the description in the blog is wrong. It's also wrong in the alternative implementation of pkg-config (pkgconf).

By rEfb1d0cd7105e: Support module dependency., it supports version dependency handling.
While it's far from pkg-config replacement, I think that we can use the script for all GnuPG software with *.pc file.
I mean, this single script for all.

The implementation by Bourne shell is not perfect. Parsing .pc file depends on glob pattern match, which would have unexpected behavior in some cases (e.g. when .pc has no variable definitions and it only has "Requires: somepackage >= 1.0", the line matches glob pattern of "*=*" which looks like variable definition).

Considering build dependency and how it should be implemented, perhaps, using awk would be much easier to avoid such parsing problem.

Anyway, it works (for me).

Initial development finished.
Now, my plan is:

• a bit more tweaks for gpg-error-config-old to support new ways (such as --variable=*)
• testing on *BSD
• not including gpg-error-config-new to next libgpg-error 1.33
  • Now, gpg-error-config-old has forward compatibility, so, no problem
  • Possibly include new gpg-error.m4???
• After 1.33, merge the branch (not directly by "merge" but merging all changes with relevant commit logs) to master of libgpg-error. This means:
  • gpg-error-config-new
  • checking difference between old and new at build-time
  • "make check" tests difference between gpg-error-config(-new) and pkg-config (if available)
• 1.34 1.33 will have all new features
• Then, we will migrate other software of our GnuPG
  • libassuan
  • libgcrypt
  • libksba
  • libnpth
  • ntbtls
  • gpgme

Here are more links, which are basically Debian specific:

• https://bugs.debian.org/643341
• https://wiki.ubuntu.com/CrossBuilding
• https://wiki.ubuntu.com/MultiarchCross

This patch D467: Enable dynamically defining pkg_config_libdir for multiarch, enables multiarch dynamic PKG_CONFIG_LIBDIR support.

I wonder if it is better not to apply this as upstream, keeping it Debian patch. If multiarch support is common, it would be better to apply.

Frankly, I still do not understand the problems with cross-compiling. Since 2014 we support SYSROOT and the respective foo-config script is installed as $SYSROOT/bin/foo-config. This guarantees that a matching config script is used and because it is a script it works on all platforms from which we are cross-building. It is also fine to install that very script in the bin dir of the (target) host; it will work there as long as host is a Unix system. So it does not matter whether it is a plain text file (a la pgk-config) or a POSIX script. The only important thing is to really install the foo-config at SYSROOOT/bin - make install does it.

So where is the problem?

• Different canonization of the triplet?
• A lot of similar files per cross target (host)?

The latter might be not really nice but given that disk space is cheap this should not be a problem for builder boxes. All kind of mixing native and cross files (e.g. include files) is an unneeded complexity and major annoyance. Without allowing to mix them strace and grep can be used to figure out faulty include dirs.

@werner, I think that the scope is different. The bug reporters' claim were basically "GnuPG's cross building is different (for them), why?". They didn't claim GnuPG were unable to be cross-build.

SYSROOT is indeed a standard way to do cross building. On the other hand, there is a non-standard way, for example, cross building with multiarch environment, which doesn't use SYSROOT.
(Here "standard" refers things in terms of GNU Operating System and its Development Environment.)

Example is: cross building for i686-linux-gnu on x86_64-linux-gnu Debian box. In this environment, it's good if a single gpg-error-config
script can automatically detect the "host" to be build to determine architecture specific path and options.

My effort is to make libgpg-error friendly as possible even for such a use case.

I did a small update to D467: Enable dynamically defining pkg_config_libdir for multiarch. The name is changed to "auto" (was: "unknown"). It now support other cases where CC is not a kind of gcc.

libassuan: Done
libksba: Done
npth: Done
ntbtls: Done
libgcrypt: Done