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}).
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 *-cofig 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.