[MacPorts] #52481: KDEPIM4 and gpgme: header conflict

[MacPorts]

#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