> what version of CMake are you using?
I'm using cmake version 3.10.0.
> Which seems at odds with your observations/comments, unless I'm
> misunderstanding what you're saying.
Well, what's for sure is that the above invocation does not compile,
but if at our root CMakeLists.txt we add
include_directories(/apps/homefs1/USER/work/.../libllvm/icc/include)
so that the invocation is now :
g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
/apps/homefs1/USER/work/.../libllvm/icc/include -isystem
/spare/local/USER/conda_root/envs/gcc6cxx14/include ...
it compiles fine.
Actually, what's odd is that the path that's being added by
set_property(TARGET global_llvm_external APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
does not materialize with
-I/apps/homefs1/USER/work/.../libllvm/icc/include
but with
-isystem/apps/homefs1/USER/work/.../libllvm/icc/include
So if -isystem are searched last, then if there's a way to tweak
INTERFACE_INCLUDE_DIRECTORIES to use -I instead of -isystem that would
also work.
David
On Fri, Oct 12, 2018 at 9:02 AM Craig Scott <craig.sc...@crascit.com> wrote:
>
>
>
> On Fri, Oct 12, 2018 at 6:42 PM David Jobet <djo...@tower-research.com> wrote:
>>
>> Hello,
>>
>> we embed in our source a copy of an ICC build of LLVM, that we import :
>>
>> add_library(global_llvm_external STATIC IMPORTED)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_CURRENT_SOURCE_DIR}/icc/include)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMCore.a)
>> set_property(TARGET global_llvm_external APPEND PROPERTY
>> INTERFACE_LINK_LIBRARIES
>> ${CMAKE_CURRENT_SOURCE_DIR}/icc/lib/libLLVMLTO.a ...)
>>
>> add_library(global_llvm INTERFACE)
>> target_link_libraries(global_llvm INTERFACE global_llvm_external)
>> add_library(global::llvm ALIAS global_llvm)
>>
>> It works fine, until someone decided to install a more recent version
>> of LLVM in its development env. (which is not ABI compatible)
>>
>> Somehow, system includes path are looked into first
>> g++ ... -I/apps/homefs1/USER/work/. -I. -isystem
>> /spare/local/USER/conda_root/envs/gcc6cxx14/include -isystem
>> /apps/homefs1/USER/work/.../libllvm/icc/include ...
>>
>> so, as with include_directories where it's possible to control the
>> ordering with BEFORE or AFTER, is there a way to tell cmake that when
>> linking against global::llvm we want the include directories needed by
>> global::llvm to be prepended (instead of appended) ?
>>
>
> While not directly answering your question, what version of CMake are you
> using? There was a change related to this area in the following merge request
> that went in for the 3.12 release:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1968
>
> The part that got my attention is the following claim in the description:
>
>> An effect of the -isystem flag is to search the directory after those
>> specified via -I flags.
>
>
> Which seems at odds with your observations/comments, unless I'm
> misunderstanding what you're saying.
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> New book released: Professional CMake: A Practical Guide
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
