#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