Hi,
We have integrated CMake and CTest and generates project in Visual Studio.
We run the tests from visual studio. When a test fails, it shows only the
message "test failed". CTest has a verbose option for knowing the details
about failed test. is it possible to integrate this verbose option in
v
Changing the subject line, since it is a great idea to use cmake.
Can I put that in my CMakeLists.txt?
Or would it be used on the command line when running cmake:
>Cmake –DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake –sysroot
I just tried it, and am still getting the error from make output. If I
I am proud to announce the second CMake 3.7 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.7
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.7/release/3.7.html
Some of the more significant c
Can I put that in my CMakeLists.txt?
Or would it be used on the command line when running cmake:
>Cmake –DCMAKE_TOOLCHAIN_FILE=cmake/toolchain.cmake –sysroot
From: J Decker [mailto:d3c...@gmail.com]
Sent: Wednesday, October 19, 2016 2:10 PM
To: Gunter, Walter E
Cc: Dave Flogeras; cmake@cmake.or
to gcc you can pass --sysroot which will bias it's internal referenced
includes and libraries
On Wed, Oct 19, 2016 at 9:57 AM, Gunter, Walter E wrote:
> The toolchain was a great suggestion.
>
>
>
> I am still having problems, but at least I know I am using the right
> toolchain:
>
> Current
The toolchain was a great suggestion.
I am still having problems, but at least I know I am using the right toolchain:
Currently, this is what I have for my toolchain:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(TOOLCHAIN_PATH /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnue
This is a complete stab in the dark, but I wonder if your clang (Xcode tools…)
needs reactivation. I know some people have reported that they’ve needed to
re-accept the license and/or reinstall the Xcode tools following the upgrade.
Again, this is just a wild guess.
> On Oct 19, 2016, at 2:44
Hi
here is all the property I had to set to produce C++/CLI (clr) targets with
cmake
target_compile_options(${project_name} PRIVATE /clr)
target_compile_options(${project_name} PRIVATE /fp:precise) #
/fp:strict is incompatible with /clr
set_property(TARGET ${project_name} PROPERTY VS
On 10/18/2016 10:32 AM, Cralle, Chris wrote:
> I need output from the hdiutil command at CPackDragNDropGenerator.cxx:258
>
> I wish it was more like CPackOSXX11Generator/CPackPackageMakerGenerator
> which saves to hdiutilOutput.log
That sounds useful. If you'd like to try adding it please see
CO
I am trying to create a managed c++ code , i want to thes clrsupport to be
true from cmake. Below is the script which i have used
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "/clr")
STRING(REPLACE "/EHsc" "/EHa" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
STRING(REPLACE "/RTC1" "" CM
Some recent configuration change (either upgrading to Sierra or CMake 3.5.0)
has prompted the following warning when running Cmake on a particular project:
CMake Error in /CMakeLists.txt:
No known features for CXX compiler
"Clang"
version 3.5.0.
==
I am using cmake (3.5.0) to compile a C++ probject on Ubuntu 14.04, which
depends on Nvidia Cudnn. It seems that the cmake does not provide the
correct paths of cudnn to the linker although I have configured the paths.
File FindCUDNN.cmake:
FIND_PATH(CUDNN_INCLUDE_DIR NAME "cudnn.h" PATHS "$ENV{C
12 matches
Mail list logo
