Changes between Version 1 and Version 2 of Ticket #40656, comment 10


Ignore:
Timestamp:
Nov 26, 2021, 4:11:17 PM (3 years ago)
Author:
ryandesign (Ryan Carsten Schmidt)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #40656, comment 10

    v1 v2  
    1717Yes, 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.
    1818
    19 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, but then 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.
     19MacPorts 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 me any reason why it couldn't, but then 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.
    2020
    2121One 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).