MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015687CMakeCMakepublic2015-08-07 04:072016-06-10 14:31
ReporterAdn 
Assigned ToGregor Jasny 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformAppleOSOS XOS Version10.9.5
Product VersionCMake 3.3 
Target VersionFixed in Version 
Summary0015687: target_include_directories(): SYSTEM option does not seem to work when targeting Xcode.
DescriptionFollowing the documentation for target_include_directories():
http://www.cmake.org/cmake/help/v3.0/command/target_include_directories.html [^]

We tried to provide the SYSTEM argument to target_include_directories(), to prevent a third party library to issue a lot of warnings. We expected it to put the library's include path on the C++ flags line, behind "-isystem", but it had actually no effect, still using this path as if SYSTEM was not given.

We attached in "Steps To Reproduce" the minimal example reproducing this problem in our environment:
*CMake v3.3.0 (also tested with v3.0.0 for the same results)
*OS X 10.9.5
*Xcode 5.1.1

There is a mailing list thread discussion this issue, that seems to point to the incriminated code:
http://www.cmake.org/pipermail/cmake/2015-August/061322.html [^]


Steps To Reproducecmake_minimum_required(VERSION 3.0)

find_package(Boost 1.49 COMPONENTS)

project(system_dependencies)
add_executable(${PROJECT_NAME} main.cpp)

target_include_directories(${PROJECT_NAME} SYSTEM PUBLIC ${Boost_INCLUDE_DIRS})
Additional InformationThere is also a Stack Overflow question:
http://stackoverflow.com/q/31722426 [^]
TagsNo tags attached.
Relationships
related to 0010837closed Gregor Jasny GCC flag -isystem not applied on OS X 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-08-07 04:07AdnNew Issue
2015-08-07 04:35Gregor JasnyNote Added: 0039250
2015-08-07 04:35Gregor JasnyAssigned To => Gregor Jasny
2015-08-07 04:35Gregor JasnyStatusnew => assigned
2015-08-07 04:41Gregor JasnyRelationship addedrelated to 0010837
2015-10-31 13:18Szymon KurekNote Added: 0039712
2015-11-02 04:46Szymon KurekNote Added: 0039717
2015-11-02 09:39Gregor JasnyNote Added: 0039829
2016-02-25 08:58AdnNote Added: 0040549
2016-02-25 09:47Gregor JasnyNote Added: 0040551
2016-02-25 09:48Gregor JasnyNote Edited: 0040551bug_revision_view_page.php?bugnote_id=40551#r2039
2016-02-26 06:32AdnNote Added: 0040554
2016-06-10 14:29Kitware RobotNote Added: 0042818
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0039250)
Gregor Jasny   
2015-08-07 04:35   
I have a proof of concept patch at home. Basically it used the same functions as for Makefile builds and puts the proper -isystem and -I flags into the CFLAGS variable list and omits putting stuff into the Xcode HEADER_SEARCH_PATHS.

It does the same for Frameworks.
(0039712)
Szymon Kurek   
2015-10-31 13:18   
Any progress on this? It's a blocker for us - the amount of warnings generated by xcodebuild for a project with boost exceeds 5 GB, crashing the compiler.



If no progress on the fix, do you know of any workaround?
(0039717)
Szymon Kurek   
2015-11-02 04:46   
Workaround: adding the CXX compilation flag --system-header-prefix=boost/
(0039829)
Gregor Jasny   
2015-11-02 09:39   
We use the following:
if(XCODE)
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -isystem ${Boost_INCLUDE_DIRS}")
endif(XCODE)
(0040549)
Adn   
2016-02-25 08:58   
Any progress on this bug ?
We also use a workaround, but it would still be great to see this fixed in a further release.
(0040551)
Gregor Jasny   
2016-02-25 09:47   
(edited on: 2016-02-25 09:48)
I had to revert the change because it broke Xcode <= 5 Did not find time to follow-up, yet. Maybe this weekend.
(0040554)
Adn   
2016-02-26 06:32   
Hi Gregor,

  Thank you for you swift response and the time you invest on this topic. We are very interested by any progress in this direction!
(0042818)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.