Re: [CMake] CUDA Support

I believe the closest equivalent to settinga CUDA_TOOLKIT_ROOT_DIR when using enable_language(CUDA) is to set either the environment variable CUDACXX or the CMake cache entry CMAKE_CUDA_COMPILER to point to the location of the nvcc compiler. However I think there are still some "features" of FindC

Re: [CMake] [cmake] [RFC] rewriting FindMKL

As a comment, would it be possible to include imported targets that encapsulate include dirs, linker arguments and compile definitions? I would say the CMake community is trying to move away from the old-style find packages that define variables instead of targets. Regards, Luis On Mon, Jan 22, 2

Re: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly

nst. In the build tree, "ldd" tool on Linux should help you determine whether your tbb or the system one is picked. On the install tree, depends on the rpath ! Regards, Luis On 13 Oct 2017 15:22, "Chris Green" wrote: On 10/13/17 3:06 AM, Luis Caro Campos wrote: Hi Chris, Are

Re: [CMake] Help: erroneous '-ltbb' getting injected into link command implicitly

Hi Chris, Are you, by any chance, using (via find_package), another library that may have been built with tbb support? I've had the exact same problem you describe with OpenCV, when my own targets link against the opencv ones. Regards, Luis On 13 Oct 2017 01:21, "Chris Green" wrote: > Hi, > >

Re: [CMake] Fwd: Re: VC2015 and Windows 7 compatibility

y/8x480de8.aspx). You may also need to add your define in "targetver.h" rather than defining it through command line, but I am unsure about this. Regards, Luis On 21 Sep 2017 22:40, "Gonzalo Garramuño" wrote: > > > El 21/09/2017 a las 11:08, Luis Caro Campos escribió

Re: [CMake] Fwd: Re: VC2015 and Windows 7 compatibility

Hi Gonzalo, Since you are using ninja files and building from command line, I suspect you are using a Visual Studio 2015 command prompt. It may be beneficial to initialise a command prompt to specifically target Windows 8.1 SDK which is the one to go to target Windows 7. First, make sure Windows

Re: [CMake] target_link_libraries - private public interface rules

I think the documentation also fails to mention that link dependencies propagate even when "PRIVATE" is used, if the target is a static library. On 22 Aug 2017 4:40 pm, "Brad King" wrote: > On 08/22/2017 11:36 AM, Robert Maynard wrote: > > The `Transitive Usage Requirements` section of the c

Re: [CMake] find_package( ITK ) with ITK version 4.8 and cmake 3.9.0-rc6 (3.1+ anyway) is like finding Dory

Hi Brian, What is the version passed to cmake_minimum_required for your project? (Typically the first line in your top-level CMakeLists.txt). I suspect if you set it to a version higher than 3.1 the warnings will disappear (I believe it is set to a version older than that, hence the policy warnin

Re: [CMake] Problem with fixup bundle and duplicate change commands on macOS

Hi Lukas, Could you provide some details? Please do correct me if any of my assumptions are wrong. You are calling FIXUP_BUNDLE on an executable created this way: add_executable(MyAppName MACOSX_BUNDLE ...), and you need are calling FIXUP_BUNDLE so that the 3rd party library dependencies are pul

Re: [CMake] Using target_link_libraries INTERFACE with static libraries

e very detailed explanation [1] provided by Craig Scott is also > interesting in this context. > > HTH, > Mario > > [1] https://cmake.org/pipermail/cmake/2016-May/063400.html > > On 2017-06-01 13:11, Luis Caro Campos wrote: > > I have the following scenario where I have

[CMake] Using target_link_libraries INTERFACE with static libraries

I have the following scenario where I have 2 static libraries, where one uses symbols from the other, and the executable needs to link against both in order to build properly. Library 'Bar' uses symbols from library 'Foo' internally, but 'Foo' is not part of the "interface" of Bar, i.e., the calli