[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:  closed
  Priority:  Normal        |  Milestone:  MacPorts Future
 Component:  base          |    Version:  2.2.0
Resolution:  fixed         |   Keywords:  haspatch
      Port:                |
---------------------------+--------------------------------

Comment (by ryandesign@…):

 Replying to [comment:16 jmr@…]:
 > So this breaks some things that parse flags and don’t know about
 -isystem, right? Specifically swig, which is used kind of a lot.
 >
 > https://lists.macosforge.org/pipermail/macports-
 dev/2014-January/025753.html
 >
 > Can we please revert this and clear or change configure.cppflags in only
 the ports that need it, or if you don’t care about old clang as per
 comment:10 just don’t set CPPFLAGS to anything by default, and reply on
 CPATH?

 I see you reverted this in r118016. I would like to reconsider that
 reversion because I stand by the change.

 It fixes a whole host of build failures due to incorrect `-I` flag
 ordering that are often not found during the normal course of updating a
 port, because they may be caused by having an older version of the same
 port installed, or by having another port installed that coincidentally
 installs headers whose files have the same names as private headers this
 port builds with. These problems either go unfixed, or it takes a MacPorts
 developer significant time and effort to track down the cause and then
 learn enough about the project's build system to integrate the fix. Our
 time and effort can be best spent elsewhere, and we can increase the
 happiness of our users by solving this whole class of problem instantly,
 centrally, without needing to bother the user with build failures and
 filing tickets.

 I have been using this patch for months without problems. This problem
 you've mentioned with swig is the first problem I've heard of. Could you
 be more specific? Could we fix that problem instead?

 I do not believe that the suggestion to rely on `CPATH` entirely solves
 the problem, because many ports will use `pkg-config` or other `-config`
 scripts, most of which will reintroduce `-I/opt/local/include` into
 `CPPFLAGS` and thus reintroduce the problem. Using
 `-isystem/opt/local/include` in `CPPFLAGS`, as my patch did, supersedes
 any `-I/opt/local/include` that may also be specified.

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