[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 larryv@…):

 Replying to [comment:3 rjvbertin@…]:
 > And why would kdepim4 have to be broken because another port suddenly
 > starts installing files with the same name at the same location?

 It doesn’t have to be broken. It can be patched to hide its gpgme++ stuff.

 > If anything, kdepimlibs4 was installing those headers long before
 > port:gpgme did

 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.
 (Granted, I’m not actually expecting many such ports.)

 > That's a direct consequence of how compiler include paths work: it's
 > simply not feasible to instruct the compiler to ignore include/gpgme++
 > when looking for <gpgme++/foo.h>.

 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?

 If that’s false, then the rest of my argument is void (obviously).

 > We should think of this as 2 ports installing different
 > implementations of a same idea which sadly can clash. Either both
 > ports cannot be allowed to install the C++ wrappers, or both must make
 > some changes - changes which in both cases are foreseen by the
 > buildsystem.

 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.

 > you'd have a point if a significant number of high-value ports could
 > now finally be installed (without depending on kdepimlibs4). It's
 > impossible for me to know if there are any such ports (for that the
 > C++ wrappers would have to be installed via a subport). But even in
 > that case: well behaved dependents will use the metadata provided by
 > port:gpgme to learn how to find the gpgme++ headerfiles.

 The port provides no such metadata. Does GPGME provide a program or
 configuration file that dependents are expected to query for the header
 location? Otherwise ports that want to use `gpgme`’s headers will have to
 explicitly look elsewhere for the headers.

 (Again, I admit that this is more philosophical than anything. I am not
 expecting a flood of ports that need GPGME’s headers.)

-- 
Ticket URL: <https://trac.macports.org/ticket/52479#comment:4>
MacPorts <https://www.macports.org/>
Ports system for the Mac operating system