Re: [CMake] CMake with two C++ compilers

or the CUDAHOSTCXX environment variable. -- Chuck Atkins Staff R Engineer, Scientific Computing Kitware, Inc. On Wed, May 8, 2019 at 7:27 AM JR Cary <mailto:c...@txcorp.com>> wrote: Is there a standard way to deal with 2 C++ compilers?  Getting both there versions, etc

[CMake] CMake with two C++ compilers

Is there a standard way to deal with 2 C++ compilers?  Getting both there versions, etc.? I need one compiler for compiling ordinary C++ code and a different one to use as the host compiler for CUDA. Thx..John Cary -- Powered by www.kitware.com Please keep messages on-topic and check the

[CMake] enable_language(CUDA) and long command lines on windows

Regarding the previous email, below The method of library construction is to first create an object library with add_library(${libname}obj OBJECT ${${LIBNAME}_SOURCES} ${${LIBNAME}_CUDASRCS}) then to create the actual library with add_library(${libname} $) and I have tried setting:

[CMake] enable_language(CUDA) and long command lines on windows

Porting our cmake build system to use enable_language(CUDA). This is a complex computational application that make use of many libraries.  Upon doing this, add_executable ended up generating a link line of 9455 chars, causing Windows cmd to fail to execute it.  In addition, the final link used

[CMake] Does enable_language(CUDA) still have the problem with reconfiguring?

Re the thread below, Does the newer, enable_languagedo a better job of not having the repeated reconfigurations and full project rebuilds as described at https://cmake.org/pipermail/cmake/2011-January/042173.html and many times after? John On 3/30/19 6:45 AM, cmake-requ...@cmake.org wrote:

Re: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015

Thanks.  All now configures with 3.9.4. On 12/12/17 5:50 AM, Brad King wrote: > On 12/11/2017 04:34 PM, John Cary wrote: >> Bill Hoffman wrote: >>> LINK: command "xilink ... /out:FortranCInterface.exe ..." failed (exit code >>> 1169) >>> LIBCMT.lib(winapisupp.obj) : error LNK2005: >>>

Re: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015

at the preprocessor is not being run. It requires -fpp to be added to the Fortran compiler flags. I do not see how to do that for CMakeFortranCompilerId.F. Tried set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -fpp") but that did not help. On 11/26/17 4:29 PM, JR Cary wrote: >

[CMake] FortranCInterface not working with 3.9.0 with Intel 2015

Works with 3.8.2. Compilers specified by -DCMAKE_C_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/icl.exe' -DCMAKE_CXX_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/icl.exe' -DCMAKE_Fortran_COMPILER:FILEPATH='C:/Program Files

[CMake] Convenience libraries with CUDA

This is partially a continuation of the issue described at http://public.kitware.com/pipermail/cmake/2015-June/060937.html, where the hope was to be able to use object libraries with cuda. There was no solution at that time, so we dropped this path, but now this has become more important. I

[CMake] Is there a way to disable adding extra libraries at the end of a link line?

Working on a just delivered Cray I am again challenged by the way that CMake adds libraries to the end of the link line that I did not specify. The Cray requires use of the compiler wrappers. After adding the appropriate libraries (hdf5, z) to my target, the link line is

Re: [CMake] cmake_check_build_system is causing a rebuild at "make install"

ilto:nilsglad...@gmail.com>> wrote: On 14.10.2015 14:51, JR Cary wrote: Thanks for your response. This is a big headache for us, as it slows down our builds tremendously. Is there any way to prevent or control this behavior? I don't see how. You

Re: [CMake] cmake_check_build_system is causing a rebuild at "make install"

Thanks for your response. This is a big headache for us, as it slows down our builds tremendously. Is there any way to prevent or control this behavior? Thx..John On 10/14/15 6:45 AM, Nils Gladitz wrote: On 14.10.2015 02:01, John Cary wrote: For future reference, one can determine what

[CMake] cmake_check_build_system is causing a rebuild at "make install"

In our use of cmake on a particular project, we noticed that after building the project, upon invoking "make install", the build starts all over again. Hence we are building the project twice. It seems that this is occurring because nearly everything depends on the target,

[CMake] CUDA OBJECT libraries?

I would like to use OBJECT libraries with CUDA. If I try cuda_add_library(foo OBJECT some .cpp files some .cu files) I get CMake Error at /opt/contrib-clangcxx11/cmake-3.2.2-ser/share/cmake-3.2/Modules/FindCUDA.cmake:1518 (add_library): OBJECT library txsbaseobj contains:

[CMake] How can one use ctest/cdash with a target that is not all?

How can one use ctest/cdash with a target that is not all? I have a project with two top-level targets, say all and other, where make all does a standard build of executables that one can test, while make other does a distinct set of actions, in particular not creating any executables, so one

Re: [CMake] How can one use ctest/cdash with a target that is not all?

Oops, found it: CTEST_BUILD_TARGET Sorry using up bandwidth.JC On 1/11/14 6:45 AM, JR Cary wrote: How can one use ctest/cdash with a target that is not all? I have a project with two top-level targets, say all and other, where make all does a standard build of executables that one can