Erroneous -isystem option generated breaking compilation
This happens when an imported target contains a
INTERFACE_INCLUDE_DIRECTORIES property of value
/usr/include (or potentially other default/system include path) and the source file contains a
INCLUDE_DIRECTORIES property of the same value. I did not see a note in the document of each stating that the two features are not compatible and I also don't think they should conflict... The
INCLUDE_DIRECTORIES property of the target does not seem to have the same issue.
The code to reproduce this is
# CMakeLists.txt project(cmake.target_include) cmake_minimum_required(VERSION 3.11) add_library(cmake-test-lib-import SHARED IMPORTED) set_target_properties(cmake-test-lib-import PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "/usr/include" IMPORTED_LOCATION /usr/lib/libc.so.6) set_property(SOURCE lib.cpp APPEND PROPERTY INCLUDE_DIRECTORIES /usr/include) add_library(cmake-test-lib SHARED lib.cpp) # set_property(TARGET cmake-test-lib APPEND PROPERTY INCLUDE_DIRECTORIES /usr/include) # This one does not lead to the error. target_link_libraries(cmake-test-lib PUBLIC cmake-test-lib-import)
// lib.cpp #include <cstdlib>
IMPORTED_LOCATION to point to any existing library and maybe also change the /usr/include to point to the path of the actual
With GNU Make generator and GCC 10.2.0 as the compiler, this results in a compiler option:
-isystem /usr/include which apparently break GCC badly... The error reported is,
[ 50%] Building CXX object CMakeFiles/cmake-test-lib.dir/lib.cpp.o /usr/bin/c++ -Dcmake_test_lib_EXPORTS -isystem /usr/include -g -Wall -Wextra -Wunused-result -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-unknown-warning-option -fasynchronous-unwind-tables -pipe -fPIC -o CMakeFiles/cmake-test-lib.dir/lib.cpp.o -c /home/yuyichao/projects/explore/trycmake/target_include_bug/lib.cpp In file included from /home/yuyichao/projects/explore/trycmake/target_include_bug/lib.cpp:3: /usr/include/c++/10.2.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next <stdlib.h> | ^~~~~~~~~~ compilation terminated.
There also seems to be a missing dependency tracking, which may be related to/caused by this issue. Adding the
target_link_libraries call only triggers a relinking even though it actually changes the include path and should trigger a recompilation as well.
I observed this when I set the include path for some of the source files that uses one library (LLVM) and then linked to yaml-cpp which sets the property on the imported target. Apparently this has happened before as well for qt-base (https://bugzilla.redhat.com/show_bug.cgi?id=1704474) but it seems that it was patched locally. I did not find a link to a cmake bug report from there...
My cmake version is 3.19.