Opened 11 years ago
Last modified 2 years ago
#42872 new defect
cmake PortGroup: don't add -I${prefix}/include to CXXFLAGS — at Initial Version
Reported by: | mojca (Mojca Miklavec) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | portgroup | Cc: | ryandesign@…, css@… |
Port: |
Description
CMake is automatically fed with too many (too early) includes of $prefix/include
:
CPPFLAGS='-I/opt/local/include' CFLAGS='-pipe -Os -I/opt/local/include -arch x86_64' CXXFLAGS='-pipe -Os -I/opt/local/include -arch x86_64'
with the following explanation in the PortGroup
:
# The environment variable CPPFLAGS is not considered by CMake. # (CMake upstream ticket #12928 "CMake silently ignores CPPFLAGS" # <http://www.cmake.org/Bug/view.php?id=12928>). # Thus, we have to add them manually to the CFLAGS and CXXFLAGS in the # pre-configure phase. if {${configure.cppflags} ne ""} { configure.cflags-append ${configure.cppflags} configure.cxxflags-append ${configure.cppflags} }
As a consequence the CMake-based installations have problems when function definitions change in an upgrade. I don't know if I should blame the developers for that or not. (In case of CLHEP, the ./configure
-based installation puts -I.
in front of CPPFLAGS
, so headers from sources are found first, but in CMake-based installation -I.
comes later.)
We should check whether we could use CMAKE_INCLUDE_PATH (-DCMAKE_INCLUDE_PATH=${prefix}/include
) instead of configure.cxxflags-append ${configure.cppflags}
for example.
See also:
Note: See
TracTickets for help on using
tickets.