[MacPorts] #40656: Use -isystem instead of -I in default configure.cppflags

[MacPorts]

#40656: Use -isystem instead of -I in default configure.cppflags
---------------------------+--------------------------------
  Reporter:  ryandesign@…  |      Owner:  macports-tickets@…
      Type:  enhancement   |     Status:  new
  Priority:  Normal        |  Milestone:  MacPorts Future
 Component:  base          |    Version:  2.2.0
Resolution:                |   Keywords:  haspatch
      Port:                |
---------------------------+--------------------------------

Comment (by ryandesign@…):

 Replying to [comment:2 ryandesign@…]:
 > However I found a mention that
 [http://public.kitware.com/Bug/view.php?id=10837#c27206 -isystem causes
 problems for C++ code on Tiger]; if I can reproduce that, then maybe we
 have to make this change only on Leopard and later.

 I have indeed seen this problem, e.g. in texlive-bin: #41528.
 But switching Tiger's default compiler from gcc-4.0 to apple-gcc-4.2
 should be the end of that problem: #41782.


 Replying to [comment:4 raimue@…]:
 > Be aware that using `-isystem` hides all warnings from the header files
 as they are treated as if they were system headers. I worry this could
 mask problems during building and make it harder to identify the cause.

 I didn't know this would hide warnings, but that's an acceptable tradeoff
 for me. Every week or so, I encounter another ticket about a build problem
 that I did not see on my system because I was using the patch in this
 ticket. It fixes so many problems with one simple change that we should
 definitely make this change.

 As for it treating headers as if they were system headers: they ''are''
 system headers—that is, they are headers installed by the MacPorts system.
 No need, IMHO, to differentiate that from headers installed by the
 operating system; they're all just headers provided by software other than
 the one being compiled. Anytime "`#include <foo>`" is written, it's
 telling the preprocessor "please include the system header named 'foo'";
 by using `-isystem`, we're telling the preprocessor (an additional place)
 where those headers may be found.

 > There is also the environment variable `CPATH` for additional include
 paths as if they were given using `-I` on the command line
 ([http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html gcc
 manual]). However, older versions of clang do not honor this setting.

 Yes, with the difference that paths specified in `CPATH` are interpreted
 as if they were given "after any paths given with `-I` options on the
 command line" which would indeed be what we want.

 MacPorts already sets `CPATH` and the corresponding `LIBRARY_PATH`, since
 several years. I'm not sure if this could completely replace our global
 `-I` / `-L` flags in CPPFLAGS and LDFLAGS. The documentation doesn't show
 my any reason why it couldn't, why haven't we stopped setting `-I` / `-L`?
 A couple years ago lack of support from older clang versions concerned me,
 but by this point in time we could afford to just blacklist them globally.

 One advantage to `-isystem` is that any path specified with both `-I` and
 `-isystem` is interpreted as if it were specified only with `-isystem`.
 This would probably fix a few additional build failures (i.e. from ports
 that use pkg-config or other -config script which drags
 `-I/opt/local/include` back into the `CPPFLAGS` which could introduce a
 build failure if the order of the `-I` flags is wrong).

-- 
Ticket URL: <https://trac.macports.org/ticket/40656#comment:10>
MacPorts <http://www.macports.org/>
Ports system for OS X