Add support for pkg-config
Closed, ResolvedPublic

Description

While introducing another dependency to a tool for building GnuPG (and its friends) is not good, providing pkg-config files for gpgme/libgcrypt/gpg-error users makes sense. It will be useful for those users. (In the past, we had a ticket: T1414: Please add pkg-config support).

It may be not good to provide the files separately along with gpgme-config/libgcrypt-config/gpg-error-config command; Both ways (*-config command and use of pkg-config file) should result same result, always, consistently.

To keep this condition (both ways, same result), the approach will be:

  • Generate *.pc file at configure time
  • Generate *-config command at configure time
  • Both *.pc file, as well as *-config command are installed
    • It's up to users which way will be used
    • GnuPG will keep using *-config command (to avoid new dependency)
  • Let *-config command reading from *.pc file
  • For implementation of *-config, we need to care about:
    • Portability (SVR4, *BSD, GNU): Only use standard Bourne Shell feature (no bashism)
    • For a while, it's OK only support basic features of pkg-config
      • Dependency between packages may be implemented later
      • Support for multiple modules may be implemented later
    • It's good not to introduce GnuPG-build only features
    • More considerations required (when we improve, we need to care about methodology of pkg-config too)
      • multilib, Multi-Arch
      • cross build
      • static link

By providing representations in a way of pkg-config (the *.pc files), it will be more easier to identify possible build problems.

gniibe created this task.Jul 23 2018, 3:35 AM
gniibe set External Link to https://bugs.debian.org/659168.Jul 23 2018, 4:11 AM
gniibe updated the task description. (Show Details)Jul 23 2018, 4:13 AM
gniibe updated the task description. (Show Details)Jul 23 2018, 4:18 AM

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.
werner added a subscriber: werner.Jul 23 2018, 10:23 AM
gniibe added a comment.EditedAug 29 2018, 4:15 AM

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.

gniibe updated the task description. (Show Details)Aug 29 2018, 4:17 AM

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).

gniibe added a comment.EditedAug 31 2018, 9:11 AM

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).

gniibe added a comment.EditedSep 4 2018, 9:12 AM

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

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.

gniibe changed the task status from Open to Testing.Oct 22 2018, 4:08 AM

Done for libgpg-error.
Will extend to other software.

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

gniibe closed this task as Resolved.Oct 26 2018, 6:56 AM