#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