[MacPorts] #40656: Use -isystem instead of -I in default configure.cppflags
MacPorts
noreply at macports.org
Thu Apr 3 16:27:16 PDT 2014
#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
More information about the macports-tickets
mailing list