Re: [CMake] IMPORTED DLL-only Target on MSVC

>From the CMake side of things yes, but MSVC requires an import library. You >could use a tool such as Digital Mars' implib tool >(https://digitalmars.com/ctg/implib.html), or use dumpbin to list all exports, >put those in a .def file and use lib to create an import library from the def >file.

Re: [CMake] Link Time Code Generation (LTGC) by default, for Release configurations of Visual Studio projects?

This would be a great feature! Currently I override my release flags by setting CMAKE__FLAGS_RELEASE_INIT and CMAKE__LINKER_FLAGS_RELEASE_INIT in a CMAKE_USER_MAKE_RULES_OVERRIDE script. Direct support for /GL and /LTCG in CMake would be great. Fewer target specifics to worry about…

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

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

; | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de> From: Robert Maynard [mailto:robert.mayn...@kitware.com] Sent: Wednesday, September 6, 2017 16:44 To: Mueller-Roemer, Johannes Sebastian <johannes.sebastian.mueller-roe...@igd.fraunhofer.de> Cc: cmake@cmake.org Subject: Re: [CMak

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

unhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de> | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de> From: Robert Maynard [mailto:robert.mayn...@kitware.com] Sent: Wednesday, September 6, 2017 15:38 To: Mueller-Roemer, Johannes Sebastian <johannes.sebastian.mueller-roe...@igd.fraunhofe

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

I'm having two issues with debug symbols for CUDA libraries on a project: 1. The PDBs are not placed where the linker later expects to find them (haven't been able to replicate this in a minimal project yet) 2. Trying to circumnavigate this issue by using "/Z7" instead of "/Zi"

Re: [CMake] Future direction for FindCUDA

Hi, we have encountered this issue as well, in our case when using thrust on the host side. We currently solve this by still using FindCUDA, even when using CMake 3.8/3.9, but only using the CUDA_*_LIBRARY and CUDA_TOOLKIT_INCLUDE variables and nothing else. Instead of modifying what FindCUDA

Re: [CMake] Yet another CMake 3.9 CUDA issue

| Fax +49 6151 155-139 johannes.mueller-roe...@igd.fraunhofer.de<mailto:johannes.mueller-roe...@igd.fraunhofer.de> | www.igd.fraunhofer.de<http://www.igd.fraunhofer.de> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Mueller-Roemer, Johannes Sebastian Sent: Monday, August 7

[CMake] Yet another CMake 3.9 CUDA issue

Hi, after solving a different issue (lack of .NET 3.5 Framework causing the CUDA MSBuild component to not work, discussion thread "Visual Studio with CUDA does not work in 3.9") and getting good results (parallel CUDA builds, yay!), I now wanted to try CMake 3.9 on a different machine, but no

Re: [CMake] What is the default build type?

Exactly. Also, CMAKE_CONFIGURATION_TYPES uses the CamelCase Versions by default, so if your CMake code breaks with that spelling, your CMakeLists.txt can be considered broken anyways... Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany Tel

Re: [CMake] Visual Studio with CUDA does not work in 3.9

al Message- From: Robert Maynard [mailto:robert.mayn...@kitware.com] Sent: Friday, June 23, 2017 15:40 To: Mueller-Roemer, Johannes Sebastian <johannes.sebastian.mueller-roe...@igd.fraunhofer.de> Cc: CMake MailingList <cmake@cmake.org> Subject: Re: [CMake] Visual Studio with CUDA does no

Re: [CMake] Visual Studio with CUDA does not work in 3.9

is needed for support when using the Visual Studio Generator(s). Otherwise you can still use ninja or the nmake generators. On Fri, Jun 23, 2017 at 7:06 AM, Mueller-Roemer, Johannes Sebastian <johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote: > The absolute minimum example &

[CMake] Visual Studio with CUDA does not work in 3.9

The absolute minimum example cmake_minimum_required(VERSION 3.9 FATAL_ERROR) project(cuda-test LANGUAGES C CXX CUDA) add_executable(cuda-test main.cu) Fails to configure with the error: CMake Error at CMakeLists.txt:2 (project): No CMAKE_CUDA_COMPILER could be found. Am I missing something,

Re: [CMake] Force MSVC runtime for debug builds

I agree that CMake should not be defining _DEBUG explicitly, as it is used by Microsoft’s headers to match the chosen runtime. Maybe this warrants a bug report on gitlab. From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Kim Kryger Sent: Monday, November 14, 2016 22:05 To: Stephan Menzel

[CMake] add_subdirectory with EXCLUDE_FROM_ALL and cmake --build (Visual Studio)

I just noticed the following issue: If I do an add_subdirectory([...] EXCLUDE_FROM_ALL) and generate a VS (2015) solution, projects added in that subdirectory generate an entirely separate solution (and therefore do not appear in the main solution at all) in the corresponding binary dir

Re: [CMake] Using Clang + Ninja on Windows?

(the default location, it’ll work with a junction point though). From: Cristian Adam [mailto:cristian.a...@gmail.com] Sent: Friday, April 22, 2016 09:15 To: Mueller-Roemer, Johannes Sebastian <johannes.sebastian.mueller-roe...@igd.fraunhofer.de> Cc: cmake@cmake.org Subject: Re: [CMake]

Re: [CMake] Using Clang + Ninja on Windows?

You are mistaken, Clang absolutely also works with MinGW. Or it did at least up to 3.7 (didn’t get around to trying 3.8 yet) From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cristian Adam Sent: Thursday, April 21, 2016 23:30 To: Johan Holmberg Cc: cmake@cmake.org

Re: [CMake] Can't get CMake to use an import library generated from a MODULE target

Why are you trying to link a MODULE? The add_library should be changed to SHARED not MODULE. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt |

Re: [CMake] Problems with transitive dependencies

You are evaluating those properties at the wrong time. Transitive properties are not passed on at configure time (they can’t be), but at generation time. Therefore to debug those values you will have to use generator expressions (except they don’t work for link_libraries). Or just look at the

Re: [CMake] Asking CMake to setup compiler for c++11

This fails for me when using Visual Studio -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139

Re: [CMake] Generated .rc files silently ignored

Hej hej, for some reason your mail was not delivered to me and I only stumbled upon it by chance in the archives (while trying to find out where another one of my mails to the list disappeared to). In any case, yes, I am adding the .rc file to my add_library command. The issue I have is that

[CMake] Generated .rc files silently ignored

While adding versioning info to a .dll I noticed that .rc files that are generated (via configure_file) are silently being ignored. Adding them via an absolute path works, but using a relative leads to it being ignored. Is this a bug or is this by design? At the very least just silently

[CMake] Function to get a list of all (recursively) linked libraries?

Is there any simple method of acquiring a list of (absolute paths, generator expressions for debug/release are ok) all libraries linked to an executable or shared target? The LINK_LIBRARIES property contains targets and aliased targets and makes creating such a list quite complicated, but CMake

Re: [CMake] Copying shared libraries in a post-build step

Only after manually changing per-user project debug settings. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax

Re: [CMake] Creating a library from subdirectories

In the example on that site an OBJECT library is created (the output consists of multiple .obj files), you used STATIC libraries instead (which each output a single .lib) -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für

Re: [CMake] Creating a library from subdirectories

-Roemer, Johannes Sebastian Sent: Wednesday, November 26, 2014 13:50 To: 'Chris Johnson'; cmake@cmake.org Subject: RE: [CMake] Creating a library from subdirectories In the example on that site an OBJECT library is created (the output consists of multiple .obj files), you used STATIC libraries instead

[CMake] out-of-tree buildable libraries and find_package

I have a project which uses a number of libraries, a bit like this: CMakeLists.txt - add_subdirectories, add_executable Lib1 - add_library Lib2 - add_library, links to/uses Lib1 As the libraries are individually useful I'd like to keep them individually buildable (i.e., out-of-tree). Obviously,

Re: [CMake] Creating a library from subdirectories

that CMake knows that those have to be linked as well. From: Chris Johnson [cxjohn...@gmail.com] Sent: Wednesday, November 26, 2014 8:45 PM To: Mueller-Roemer, Johannes Sebastian Cc: cmake@cmake.org Subject: Re: [CMake] Creating a library from subdirectories I

Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

[mailto:cmake-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, November 25, 2014 13:40 To: cmake@cmake.org Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... Mueller-Roemer, Johannes Sebastian wrote: produces a file containing

Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... Mueller-Roemer, Johannes Sebastian wrote: It appears that wasn't really the issue, but rather that I had my CMake minimum version set to 2.8.11 and not 2.8.12. See the reply from Nils and the documentation link I posted previously

Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT...

] On Behalf Of Stephen Kelly Sent: Tuesday, November 25, 2014 16:14 To: cmake@cmake.org Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... Mueller-Roemer, Johannes Sebastian wrote: For clarification: As an imported target can't have debug and optimized keywords, I can't

[CMake] BUILD_INTERFACE genex used even in install(EXPORT...

I am trying to add a library via it's variable(s) in an installed (static library) target, but BUILD_INTERFACE appears to be used for the generation of *-targets-*.cmake even when using install(EXPORT...), instead of INSTALL_INTERFACE: CMakeLists.txt [...] target_link_libraries(${PROJECT_NAME}

Re: [CMake] What generator(s) should be used for MinGW-w64?

I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The main difference between MinGW-w64 and the original MinGW is that it is far more up to date. Binary packages can be found here: http://mingw-w64.sourceforge.net/download.php I generally recommend using the mingw-builds

Re: [CMake] What generator(s) should be used for MinGW-w64?

-Roemer, Johannes Sebastian Cc: cmake@cmake.org Subject: RE: [CMake] What generator(s) should be used for MinGW-w64? On 2014-10-31 08:14- Mueller-Roemer, Johannes Sebastian wrote: I have only used MinGW-w64 for years and MinGW Makefiles works just fine. The main difference between MinGW-w64

[CMake] INTERFACE_LINK_LIBRARIES and CMP0028

The behavior of the transitive INTERFACE_LINK_LIBRARIES combined with CMP0028 seems very broken to me. For libraries using a module (such as ZLIB), I can simply do a find_package in one of my libraries' CMakeLists.txt and link to it in a different CMakeLists.txt without issues. If I do the same