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

2017-07-27 Thread David Demelier
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

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

2017-07-27 Thread Eric Noulard
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

[CMake] Correct handling of absolute/relative installation paths

2017-07-27 Thread 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_name/) where to install extra data. I want to let the

[CMake] cmakedefine based on find_package

2017-07-27 Thread Aaron Boxer
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,

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

2017-07-27 Thread J Decker
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/)

Re: [CMake] cmakedefine based on find_package

2017-07-27 Thread Aaron Boxer
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

[CMake] CMake and Learning from bad examples

2017-07-27 Thread Brian Davis
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?

2017-07-27 Thread Brian Davis
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

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

2017-07-27 Thread Brian Davis
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?

2017-07-27 Thread Christian Mazakas
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

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

2017-07-27 Thread J. Caleb Wherry
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

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

2017-07-27 Thread Ben Gregorski
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

Re: [CMake] CMake and Learning from bad examples

2017-07-27 Thread Brian J. Davis
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 ) #...

[CMake] CMake 3.9 change to dependencies of object compilation

2017-07-27 Thread Puetz Kevin A
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

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

2017-07-27 Thread Christopher Broadbent
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

[Cmake-commits] CMake branch, master, updated. v3.9.0-351-g1ed58b6

2017-07-27 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 1ed58b686c0f7b8690e89e1b6a7ffd6fb6dcee60 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.9.0-353-gab17dc6

2017-07-27 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via ab17dc6befdde5cebafc83f198793dd751454ea0 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.9.0-354-gbfb40bc

2017-07-27 Thread Kitware Robot
_VERSION_MINOR 9) -set(CMake_VERSION_PATCH 20170727) +set(CMake_VERSION_PATCH 20170728) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/