[MacPorts] #52479: gpgme: install headers in a private location to avoid conflict and/or header confusion

[MacPorts]

#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