gpgme: install headers in a private location to avoid conflict and/or header confusion

[RJVB (René Bertin)]

port:gpgme was recently updated to 1.7.0 and to build the C++ wrappers (but only when using libc++, for some reason).

Several issues result from this:

• port:kdepimlibs4 installs its own gpgme++ libraries and headers; unmodified those go into ${prefix}/include/gpgme++ and thus clash with the ones from port:gpgme

• KDE actually maintains its own C++ wrappers (fork or original I don't know). It seems that (very recent) KF5 code can co-exist with the headers from port:gpgme, but the KDE4 code that uses these C++ wrappers is now old and mostly unmaintained. It is unlikely that it will build and run against the 1.7.0 gpgme++ wrappers without significant modification of the build system and code (see ​https://trac.macports.org/ticket/52342 and ​https://trac.macports.org/ticket/52470). The 1.7.0 gpgme C libraries are fine, though.

The library binaries from port:kdepimlibs4 and port:gpgpme do not clash, so the main issue at hand is to avoid headerfile confusion where a gpgme++ header is included from port:gpgme when one from port:kdepimlibs4 is required, or vice versa.

It is trivial to reconfigure port:kdelibs4 such that headers from KDE4 ports are installed into, say, ${prefix}/include/KDE4. This has been proposed already as it is required for concurrent installation of KDE4 and KF5 ports.

It is relatively trivial to do something similar with port:gpgme, and the attached patch contains an implementation. I tested this approach and can confirm that

• The KDEPIM4 ports as well as port:kde4-runtime build and run provided the KDE4 headers are installed as described above
• kf5-gpgmepp and kf5-kwallet also build (with an upstream patch to support gpgme 1.7). I have not yet made ports for other KF5 software that uses gpgme.

As far as I know, installing the C++ headers is a new feature in port:gpgme 1.7 and as such I *presume* that only few ports depend on it as yet. Either way, the proposed change should be completely transparent and doesn't change anything link dependencies. No rev-bumping of dependents is required. However, it might be useful to add a variant to control building (or omission) of the C++ wrappers.

See also ​https://bugs.gnupg.org/gnupg/issue2733