MantisBT - CMake
View Issue Details
0015970CMakeCMakepublic2016-02-11 13:442016-06-10 14:31
Kitware Robot 
0015970: CMake changes order of include directories when a directory is specified both as a SYSTEM and non-SYSTEM include
I ran into a problem recently where a package I was building set a SYSTEM include directory which was already a non-SYSTEM include directory imported from a dependency. When this happened, CMake dropped the non-SYSTEM directory in favor of the SYSTEM one, causing my build to fail.

According to GCC [1], it gives precedence to non-SYSTEM include directories, and specifying both for the same path produces a warning.

[1] [^]
> All directories named by -isystem are searched after all directories named by -I, no matter what their order was on the command line. If the same directory is named by both -I and -isystem, the -I option is ignored. GCC provides an informative message when this occurs if -v is used.

With CMake, if both are specified, it drops the non-SYSTEM include and fails silently. For example, when building this project with any recent version of CMake on Linux, the build command is:

/usr/bin/c++ -isystem /path/to/overlay/devel/include -I/opt/ros/indigo/include -o CMakeFiles/foo.dir/foo.cpp.o -c /home/jbohren/scratch/isystem/foo.cpp

But with the three `incude_directory` options given in `CMakeLists.txt`, I would expect it to read:

/usr/bin/c++ -I/path/to/overlay/devel/include -I/opt/ros/indigo/include -isystem /path/to/overlay/devel/include -o CMakeFiles/foo.dir/foo.cpp.o -c /home/jbohren/scratch/isystem/foo.cpp

Even the following would maintain the order of the search paths, since the non-SYSTEM directories are all scanned before the SYSTEM ones:

/usr/bin/c++ -I/path/to/overlay/devel/include -I/opt/ros/indigo/include -o CMakeFiles/foo.dir/foo.cpp.o -c /home/jbohren/scratch/isystem/foo.cpp
Build this trivial CMake project to observe the effect: [^]
No tags attached.
Issue History
2016-02-11 13:44jbohrenNew Issue
2016-06-10 14:29Kitware RobotNote Added: 0042938
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

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.