[CMake] Listing all the include directories

2018-03-26 Thread Saad Khattak
Hi, I have many libraries and packages that are being linked using target_link_libraries(...) where CMake takes care of the include directories. There are cases where I get compile errors because I don't know the exact include directories. I thought perhaps I could get the include directories of

[CMake] find_library fails when cross compiling

2018-03-26 Thread Oliver Dain
Hi, I have some find_library lines like the following: find_library(protobuf_protobuf protobuf PATHS /Users/oliverdain/Documents/code/revl/.install/${ARCH}/${VARIANT}/protobuf/3.4.1.r1/lib NO_DEFAULT_PATH ) target_link_libraries(ml_editing PUBLIC ${protobuf_protobuf}) These work find when $ARCH

Re: [CMake] file(TO_NATIVE_PATH ... ) and cross-compiling

2018-03-26 Thread Miroslav Keš
I'm cross-compiling in Windows to another target system (VxWorks) but this is not so important. I thought the idea behind the TO_NATIVE_PATH option was that the internal CMake path representation could be transformed to the system native path so that external programs that rely on the native pa

[CMake] MSVC C features

2018-03-26 Thread Harry Mallon
Could MSVC be made to work with target_compile_features for C language features? I assume we would need an MSVC-C.cmake file with definitions. At a glance I imagine something simple would do? * C90 available for all supported MSVC * C99 supported/default from MSVC 18.0 = 2013 (https://blogs.msd

Re: [CMake] target_compile_features no known features for CXX compiler for clang 9.0

2018-03-26 Thread Brad King
On 03/20/2018 08:52 PM, Rick Mann wrote: > Xcode (Version 9.2 (9C40b)) That works with CMake 3.11.0-rc4 AFAIK. > CMake Error at cmake/AddCeresCXX11RequirementsToTarget.cmake:70 > (target_compile_features): > target_compile_features no known features for CXX compiler > > "Clang" > > versi

Re: [CMake] Cmake Frameworks and Bitcode

2018-03-26 Thread Brad King
On 03/26/2018 04:24 AM, Cameron Palmer wrote: > However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn't > change anything as far as I can tell. The target is still linked with > -headerpad_max_install_names and the linker still complains. Oops, I mixed up functionality with other

Re: [CMake] CMAKE_SYSROOT and CMAKE_OSX_SYSROOT

2018-03-26 Thread Craig Scott
On Mon, Mar 26, 2018 at 8:19 PM, James Weir wrote: > I’ve recently been experimenting with using Conan as a package manager for > our C++ components, the good news is most things work really well but I’ve > come across something which I’m not sure what the behaviour should be with > regards to CM

[CMake] CMAKE_SYSROOT and CMAKE_OSX_SYSROOT

2018-03-26 Thread James Weir
I’ve recently been experimenting with using Conan as a package manager for our C++ components, the good news is most things work really well but I’ve come across something which I’m not sure what the behaviour should be with regards to CMake. The problem occurs for me when building for Darwin ta

Re: [CMake] Cmake Frameworks and Bitcode

2018-03-26 Thread Cameron Palmer
Quite possible I’m misunderstanding something, but… As you said, I really don’t care much at this point about the RPATH. However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn’t change anything as far as I can tell. The target is still linked with -headerpad_max_install_names an