[CMake] Correct handling of absolute/relative installation paths

Hello, I'm still trying to find a correct solution to handle user specified installation paths. Let's consider two kind of paths: - WITH_BINDIR (default: bin/) where to install executables, - WITH_DATADIR (default: share/project_name/) where to install extra data. I want to let the use

Re: [CMake] Correct handling of absolute/relative installation paths

2017-07-27 12:28 GMT+02:00 David Demelier : > Hello, > > I'm still trying to find a correct solution to handle user specified > installation paths. > > Let's consider two kind of paths: > > - WITH_BINDIR (default: bin/) where to install executables, > - WITH_DATADIR (default: share/project_nam

Re: [CMake] Correct handling of absolute/relative installation paths

It's also handy to get installation paths from GNUInstallDirs https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html especially if you expect to install libs on linux which either go to lib or lib64. many things that install to windows just supply a standard base path (/program files/) and

Re: [CMake] Correct handling of absolute/relative installation paths

Le 27/07/2017 à 13:08, Eric Noulard a écrit : 2017-07-27 12:28 GMT+02:00 David Demelier >: Hello, I'm still trying to find a correct solution to handle user specified installation paths. Let's consider two kind of paths: - WITH_BINDIR

[CMake] cmakedefine based on find_package

Hello, I am using find_package to find the OpenCL install on my system. Finding the package sets OPENCL_FOUND to true. I would like to create a #define in the code that will match this cmake variable, so I have set #cmakedefine HAVE_OPENCL @OPENCL_FOUND@ in my config.h.cmake.in file. However, I

Re: [CMake] cmakedefine based on find_package

Never mind, figured it out :) #cmakedefine OPENCL_FOUND On Thu, Jul 27, 2017 at 9:23 AM, Aaron Boxer wrote: > Hello, > > I am using find_package to find the OpenCL install on my system. > Finding the package sets OPENCL_FOUND to true. > I would like to create a #define in the code that will mat

[CMake] Incorrect path to network drive location when installing libraries

Hello, I have a library project (headers + libs) that I want to install onto a Windows network drive location. The project is created on my local drive as an out-of-source build. When I use install(DIRECTORY ...) the network location is written correctly into the cmake_install.cmake file as //foo

Re: [CMake] Android NDK, clang, and ODR violations

On 28/07/2017 02:28, Dan Albert wrote: (in case threading doesn't work since I'm not a list member and can't reply to the original message: https://cmake.org/pipermail/cmake/2017-July/065886.html) I'm pretty sure -Wl,--detect-odr-violations is just giving you false positives. Note that the wa

[CMake] CMake 3.9 change to dependencies of object compilation

I saw the following in the CMake 3.9 release notes, but didn't immediately realize all the implications. Sorry for not catching this during the -rc phase... . The Ninja generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custo

[CMake] CMake and Learning from bad examples

In latest CMake Doc for cmake modules at: https://cmake.org/cmake/help/v3.0/module/CMakePackageConfigHelpers.html#module:CMakePackageConfigHelpers I find: Example using both configure_package_config_file() and write_basic_package_version_file(): CMakeLists.txt: set(INCLUDE_INSTALL_DIR include/

[CMake] CMake 3.8+ and CUDA as a first class language, but not for Visual Studio... err what?

Reading: https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda Can someone explain to me how CUDA is now supported as a first class language, -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offe

[CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

Can someone explain to me the meaning of the statement at: https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda Make learned to support CUDA as a first-class language that can be enabled via the project() and enable_language() commands. CUDA is currently supported by the Makefile

Re: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

Probably means no more hacky MSBuild custom tasks which can't be parallelized. On Jul 27, 2017 6:07 PM, "Brian Davis" wrote: > > Can someone explain to me the meaning of the statement at: > > https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda > > > Make learned to support CUDA

Re: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

Not sure I understand your question but Visual Studio support just lagged a version for that feature. It is available in CMake 3.9: https://cmake.org/cmake/help/v3.9/release/3.9.html Or are you asking before this version how was CUDA supported? -Caleb On Thu, Jul 27, 2017 at 9:07 PM Brian Davis

Re: [CMake] CMake and Learning from bad examples

Also at https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html?highlight=configure_package_config_file set(INCLUDE_INSTALL_DIR include/ ... CACHE ) set(LIB_INSTALL_DIR lib/ ... CACHE ) set(SYSCONFIG_INSTALL_DIR etc/foo/ ... CACHE ) #... include(CMakePackageConfi

[CMake] error on using cmake

Hello. I tried to compile LTP using cmake on Windows 10 with Visual Studio compiler ... However, "CMakeOutput.log" says that The system is: Windows - 10.0.14393 - AMD64. And I Installed Windows 10 SDK but the same error keeps occurring. Hope your help. Waiting for your reply. _201707201

Re: [CMake] error on using cmake

You need visual studio build tools... https://www.visualstudio.com/downloads/ way at the bottom of the page... Build Tools for Visual Studio 2017 or for 2015... https://www.microsoft.com/en-us/download/details.aspx?id= 48159 On Thu, Jul 27, 2017 at 11:20 PM, c <1026863...@qq.com> wrote: > Hello