#52479: gpgme: install headers in a private location to avoid conflict and/or header confusion --------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: haspatch Port: gpgme | --------------------------+-------------------------------- Comment (by rjvbertin@…): Replying to [comment:4 larryv@…]:
It doesn’t have to be broken. It can be patched to hide its gpgme++ stuff.
That is part of the solution, but even when that's done it still must not find the newer gpgme++ stuff.
And? My concern is that future ports will all have to be told to look in
a nonstandard location to use the public headers now provided by GPGME. The point is that this is not true for well-behaved ports. They will use the cmake file provided by gpgme, which will tell them exactly to look. Just like it does now, except that the location provided will be slightly different.
Setting `-I/opt/local/include/KDE4 -I/opt/local/include` wouldn’t cause that compilation to find `/opt/local/include/KDE4/gpgme++/foo.h` first?
You'd expect that because /opt/local/include isn't a default location like /usr/include or /usr/local/include, but that's not my experience. It's also my experience that KDE and in general any project of even moderate complexity that uses cmake will have lots of -I and -isystem arguments in its compiler invocations, which makes it almost impossible to hierarchise the search path. This is easier with the linker search path. There you can precede a library spec with a -L option that gives its location. But headers are included in the source, *after* the full search path has been set. To make things a bit more complicated: you can easily have a KDE4 header that calls for a gpgme++ header, but somewhere else a non-KDE4 header is included that also calls for a gpgme++ header. How do you decide which to include? Either way, I have grappled with this quite a bit back when I was setting up my KF5 ports so that they can co-install with the KDE4 equivalents. It's probably not impossible to do that without putting the KDE4 headers somewhere where they cannot be picked up by accident (the KF5 headers already are), but it's practically not feasible. With autoconf-based build systems it's still doable (usually) to patch the resulting Makefile(s) or make.conf, but with CMake that becomes a nightmare. There are lots of make files, most that contain the actual tidbits to patch nicely hidden ... and they can be regenerated at any moment during a build.
I don’t understand. The few ports that already use private headers/libraries are expected to keep them out of sight to prevent issues with other builds. The ports that publicly provide the same headers/libraries are not expected to do the same.
I don't know the exact story behind gpgme++, and why KDE have their own version/fork/branch. I think there's been a confusion here between private headers and installing public headers to what I called a private location, for lack of a better term. Until now, kdepimlibs4 provided the gpgme++ headers and libraries, period. This explains why certain ports depend on kdepimlibs4: for gpgme++ (in kde4-runtime it's the kwalletd which requires gpgme++). This is how my KDE4-based Linux box provides gpgme++, and even if you look at the latest Ubuntu you'll see that gpgme++ is provided through KDE (KF5) gpgmepp. The gpgme tarball is used only to install the C interface, not the C++ wrappers.
The port provides no such metadata. Does GPGME provide a program or configuration file that dependents are expected to query for the header location?
Yes: GpgmeppConfig.cmake
Otherwise ports that want to use `gpgme`’s headers will have to explicitly look elsewhere for the headers.
Ports that don't use cmake indeed will. But I wonder how many of those there are. Remember, Ubuntu only provides the KF5 gpgmepp variant, which puts its headers into /usr/include/KF5/gpgme++ . I think they would have reconsidered that if there were a lot of software that doesn't use cmake (or even requires the non-KDE gpgme++ variant). But what's worse, allow a conflict situation to occur where you can either install a whole family of ports (KDE) or else a few other ports that don't work with KDE's gpgme++ ... or a situation where some of those few ports have to be told to look in a specific location for some of their headers?
(Again, I admit that this is more philosophical than anything. I am not expecting a flood of ports that need GPGME’s headers.)
I understand it's a matter of principal, and I also would have liked an easy way to use just port:gpgme instead of the C libraries from that port and then C++ wrappers (for those C libraries!) from either KDE or possibly gpgme. That's why I made time for looking into this as soon as I caught wind of the issue. But it really seems we have to be practical here, at least to implement a fast solution for the current deadlock. I've asked about kdepim4 on the kdepim ML and I have contacted one of the KF5 gpgmepp maintainers who's also involved with gpgme itself about their roadmap and intentions. And the gpgme bug report I filed explains why I install gpgme's headers to a dedicated location so there too feedback can come about other solutions.
If GPGME is only now providing public C++ bindings, then what is KDE installing? I don’t really understand what’s going on there.
KDE installs a slightly different variant of the same thing, with slightly different headers and using an additional library (for threaded operation). KDE code based on KDE's latest version can build using the headers from gpgme by including boost headers itself that were dropped from gpgme's C++ wrappers. This is at least the case for the KWallet framework. I don't know if this is indeed a general principle, but it might not be impossible to get kdepim4 to build with gpgme's headers too. I hope to have another look at that tomorrow. BTW: KF5 KWallet picks up the gpgme++ headers from their new location without any need for manual intervention. -- Ticket URL: <https://trac.macports.org/ticket/52479#comment:6> MacPorts <https://www.macports.org/> Ports system for the Mac operating system