[MacPorts] #52481: KDEPIM4 and gpgme: header conflict
MacPorts
noreply at macports.org
Sun Oct 2 15:34:37 CEST 2016
#52481: KDEPIM4 and gpgme: header conflict
--------------------------+---------------------
Reporter: rjvbertin@… | Owner: nicos@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.3.4
Resolution: | Keywords:
Port: kdepimlibs4 |
--------------------------+---------------------
Comment (by rjvbertin@…):
(continuing from https://trac.macports.org/ticket/52479#comment:11)
As I tried to explain, the various -I and -isystem options are all given
in one big set of command line arguments when you finally invoke the
compiler, and they're not in any way linked at that point to specific
include files. IOW, there's no way to tell the compiler to get a
particular header from directory B but not directory A if both have to be
on the search path.
It also wouldn't make sense for a compiler to search directory A ten times
if it has been passed in that many times with -I or -isystem. So I think
what happens is that the compiler compiles all those search locations into
a single graph which is then sorted to correspond to the actual directory
layout. IOW, if you specify both /opt/local/include and
/opt/local/include/KDE4 (and you have to), the higher-up directory will be
searched first, and so /opt/local/include/gpgme++/foo.h would be found and
not /opt/local/include/KDE4/gpgme++/foo.h .
NB: this form or prioritising instead of doing it the other way round
makes sense : there are quite a few system headers that do things like
/usr/include/signal.h which includes /usr/include/sys/signal.h . Suppose
someone does `-I /usr/include/sys` for an obscure reason; this probably
should not cause `#include <signal.h>` to include sys/signal.h .
--
Ticket URL: <https://trac.macports.org/ticket/52481#comment:11>
MacPorts <https://www.macports.org/>
Ports system for the Mac operating system
More information about the macports-tickets
mailing list