MantisBT - CMake
View Issue Details
0015464CMakeCMakepublic2015-03-21 04:462016-01-04 11:52
socantre 
Gregor Jasny 
normalminoralways
closedfixed 
Apple MacOS X10.4.10
CMake 3.2.1 
CMake 3.4CMake 3.4 
0015464: target_include_directories(tgt SYSTEM PUBLIC foo) adds include path with -I instead of -isystem
With the ninja generator and AppleClang on OS X the include flag -I is used instead of -isystem when include directories are added to specific targets

A global include_directories(SYSTEM headers) uses the correct -isystem flag
mkdir tmp && cd tmp
touch main.cpp
cat << EOF > CMakeLists.txt
cmake_minimum_required(VERSION 3.2)
project(test)
add_executable(main main.cpp)
target_include_directories(main SYSTEM PUBLIC include)
EOF
mkdir build && cd build
cmake -G Ninja ..
grep build.ninja -e "-I../include"
-- The C compiler identification is AppleClang 6.0.0.6000057
-- The CXX compiler identification is AppleClang 6.0.0.6000057
No tags attached.
Issue History
2015-03-21 04:46socantreNew Issue
2015-03-21 06:15Stephen KellyNote Added: 0038268
2015-03-23 09:37Brad KingNote Added: 0038274
2015-03-23 20:21socantreNote Added: 0038283
2015-08-09 07:37Gregor JasnyAssigned To => Gregor Jasny
2015-08-09 07:37Gregor JasnyStatusnew => assigned
2015-08-09 16:56Gregor JasnyNote Added: 0039256
2015-08-09 17:02Gregor JasnyNote Edited: 0039256bug_revision_view_page.php?bugnote_id=39256#r1864
2015-08-09 17:02Gregor JasnyNote Edited: 0039256bug_revision_view_page.php?bugnote_id=39256#r1865
2015-08-10 09:48Brad KingNote Added: 0039260
2015-08-10 15:43Gregor JasnyNote Added: 0039262
2015-08-12 09:29Brad KingNote Added: 0039269
2015-08-12 09:29Brad KingStatusassigned => resolved
2015-08-12 09:29Brad KingResolutionopen => fixed
2015-08-12 09:29Brad KingFixed in Version => CMake 3.4
2015-08-12 09:29Brad KingTarget Version => CMake 3.4
2016-01-04 11:52Robert MaynardNote Added: 0040113
2016-01-04 11:52Robert MaynardStatusresolved => closed

Notes
(0038268)
Stephen Kelly   
2015-03-21 06:15   
Changing the line to

 target_include_directories(main
   SYSTEM PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/include")

fixes the behavior.

I don't remember whether relative PUBLIC directories are supposed to be supported anyway...
(0038274)
Brad King   
2015-03-23 09:37   
Re 0015464:0038268: IIRC the target properties do not support relative paths but the target_* commands are supposed to transform relative paths to full paths when populating the target properties.
(0038283)
socantre   
2015-03-23 20:21   
Yeah, according to http://www.cmake.org/cmake/help/v3.2/command/target_include_directories.html, [^] this command does accept relative paths:

"Specified include directories may be absolute paths or relative paths."

It also gives an example that uses relative paths, inside the generator expressions.
(0039256)
Gregor Jasny   
2015-08-09 16:56   
(edited on: 2015-08-09 17:02)
I pushed the relative-target-system-include topic branch with a proposed fix. Now I see -isystem for both: the actual target and the interface consumers:

cmake_minimum_required(VERSION 3.3)
add_library(foo foo.cpp)
target_include_directories(foo SYSTEM PUBLIC bar)
add_library(bar foo.cpp)
target_link_libraries(bar PUBLIC foo)


Now the question is how to write a test for this? Would it make sense to extend the IncludeDirectories/SystemIncludeDirectories test?

(0039260)
Brad King   
2015-08-10 09:48   
Re 0015464:0039256: Yes, the IncludeDirectories/SystemIncludeDirectories already runs under conditions where we know we can test for the use of -isystem.
(0039262)
Gregor Jasny   
2015-08-10 15:43   
I added the two test cases which failed before my change and succeed now.

Please review and merge to next.
(0039269)
Brad King   
2015-08-12 09:29   
Re 0015464:0039262: After minor tweaks the changes are now:

 target_include_directories: Support relative SYSTEM include dirs
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5790aca4 [^]

 cmTarget: Remove unused AddSystemIncludeDirectories overload
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c076a8b [^]
(0040113)
Robert Maynard   
2016-01-04 11:52   
Closing resolved issues that have not been updated in more than 4 months.