Re: [CMake] Proper process for static & shared variants of config packages?

> On Sep 1, 2017, at 10:39 AM, Robert Dailey wrote: > > Suppose I have a library target and I setup a config package for it > and install target exports for it. What is the process for supporting > installation of the shared library and static library variants (maybe >

[Cmake-commits] CMake branch, master, updated. v3.9.1-744-gde80352

_VERSION_MINOR 9) -set(CMake_VERSION_PATCH 20170906) +set(CMake_VERSION_PATCH 20170907) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] Adding compile and build type tests to CMake/CTest

The `add_test` function can run whatever command you want it to, including compiling a target: add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) add_test(NAME foo_compile_test COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $

Re: [CMake] Configuration packages & versioning for parallel installations

Hi, On Thu, Sep 7, 2017 at 12:26 AM, Robert Dailey wrote: > First obvious question is: Should this even be a concern? Yes, definitely! > The > cmake-packages documentation doesn't really touch on versioning, but > there are a couple of concerns I see when you

Re: [CMake] [cmake-developers] How should config packages handle components?

In my projects I always, have external dependencies with finder module providing exported (imported in my project) targets, so my targets (one per file) always have a list of `Vendor::target`. Some of them are mine (i.e. your type 2 -- built by the same project). I wrote a helper module and a

Re: [cmake-developers] How should config packages handle components?

In my projects I always, have external dependencies with finder module providing exported (imported in my project) targets, so my targets (one per file) always have a list of `Vendor::target`. Some of them are mine (i.e. your type 2 -- built by the same project). I wrote a helper module and a

[CMake] Configuration packages & versioning for parallel installations

First obvious question is: Should this even be a concern? The cmake-packages documentation doesn't really touch on versioning, but there are a couple of concerns I see when you want users to be able to install (with CMake) multiple versions of the same library side-by-side: 1. The library files

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

Yes From: Robert Maynard [robert.mayn...@kitware.com] Sent: Wednesday, September 06, 2017 6:58 PM To: Mueller-Roemer, Johannes Sebastian Cc: cmake@cmake.org Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues So it works when they are

[CMake] configuration packages, IMPORTED targets, and global scope

So it took me a while to figure out why find_package() calls I was making (with CONFIG) option were not accessible outside of the directory in which it was invoked. I realized that all targets seem to be global by default except IMPORTED targets (according to add_library() docs). I find this

[Cmake-commits] CMake branch, master, updated. v3.9.1-743-g05294a0

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 05294a09162d4c503203863149a5a552b321817b (commit) via

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

So it works when they are separate gen-code options, but fails when they are combined. Is that correct? On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian < johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote: > The long form fills the Code Generation field with >

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

The long form fills the Code Generation field with compute_20,sm_20;compute_20,compute_20 (the default without gencode parameters is compute_20,sm_20) and results in the following command line: D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU Computing

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

Yes I was responding to comment 3. I am curious, does the longer form signature "-gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=compute_20" work correctly? CMake has to parse the gencode flags and move them to special msbuild entries, and I wonder if there is a bug when

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

If the comment is wrt 3., the result is the same no matter if I use a space or an equals sign, if I double escape the quotes (e.g., use the value as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS becomes compute_20,"sm_20,compute_20" instead of compute_20,sm_20,compute_20,

Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues

As far as gencode goes, your line has errors. With CUDA 8 it should look like: -gencode arch=compute_20,code=\"sm_20,compute_20\" On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian < johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote: > I’m having two issues with debug

[CMake] How should config packages handle components?

On 2017-09-05 14:33-0500 Robert Dailey wrote: In the case where I'm exporting 1 target.cmake script per component for a single package, could someone provide an example on how to manage dependencies? There are 2 types of dependencies: 1. Dependencies on external packages 2. Cross-dependencies