Re: [CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017

2017-08-11 Thread Andrea Borsic 

Hi,

Thanks for your pointers, problem solved.

I have upgraded to CMake 3.9.1 (I don't think this matters though) and I 
switched to using the new CUDA CMake support as at your point 3). I am 
also using CUDA 9 RC which supports VS2017 (I was testing under CUDA 8 / 
CUDA 9 earlier, but just forgot to mention this). Now all builds 
successfully.


I am attaching the updated CMakeLists.txt file for the record.

Thanks, Best Regards,

Andrea



On 8/10/2017 4:28 PM, Robert Maynard wrote:

So you are going to have two issues.

1. The FindCUDA module has not been updated to handle VS2017. The
issue is that the VCInstallDir variable now returns a different
relative path to the compiler than it previously did. If you can
determine the new logic a patch fixing this behavior be great.

2. It doesn't look like CUDA 8.0 supports VS2017 (
http://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html#system-requirements
).

3. You could also look at using the new CMake 3.9 cuda support (
https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/
).

On Thu, Aug 10, 2017 at 5:49 AM, Andrea Borsic  wrote:

Hi All,

I am working on this platform:

Windows 10 64bit
Visual Studio 2015 Community Edition
Visual Studio 2017 Community Edition
CUDA 8.0
CMake 3.9

I am in the middle of switching from VS2015 to VS2017, but CUDA projects
fail to properly compile under VS2017 as the compiler/linker fail to find
tools on the path setup by CMake. I believe this is bug/incompatibly of the
CMake FindCUDA module with VS2017.

To reproduce the problem I am attaching a tiny project

main.cu is a minimal CUDA example from the web
CMakeLists.txt is a CMake file that leads to a successful build under VS2015
and unsuccessful under VS2017
Output VS2015 is the output from building the project under VS2015 (all
targets built OK)
Output VS2017 is the output from building the project under VS2015 (1 target
OK one target fails)

I have noticed also that oddly under VS2017 an "x64" and "main.dir"
directories are created outside the build dir, and at the level of the
source directory.

I thought of reporting this to the list, and any help is welcome,

Thank you and Best Regards,

Andrea


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake


#include 

//
// Nearly minimal CUDA example.
// Compile with:
//
// nvcc -o example example.cu
//

#define N 1000

//
// A function marked __global__
// runs on the GPU but can be called from
// the CPU.
//
// This function multiplies the elements of an array
// of ints by 2.
//
// The entire computation can be thought of as running
// with one thread per array element with blockIdx.x
// identifying the thread.
//
// The comparison i>>(da, db);

//
// Copy output array from GPU back to CPU.
//
cudaMemcpy(hb, db, N*sizeof(int), cudaMemcpyDeviceToHost);

for (int i = 0; i

Re: [CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017

2017-08-10 Thread Robert Maynard 
So you are going to have two issues.

1. The FindCUDA module has not been updated to handle VS2017. The
issue is that the VCInstallDir variable now returns a different
relative path to the compiler than it previously did. If you can
determine the new logic a patch fixing this behavior be great.

2. It doesn't look like CUDA 8.0 supports VS2017 (
http://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html#system-requirements
).

3. You could also look at using the new CMake 3.9 cuda support (
https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/
).

On Thu, Aug 10, 2017 at 5:49 AM, Andrea Borsic  wrote:
> Hi All,
>
> I am working on this platform:
>
> Windows 10 64bit
> Visual Studio 2015 Community Edition
> Visual Studio 2017 Community Edition
> CUDA 8.0
> CMake 3.9
>
> I am in the middle of switching from VS2015 to VS2017, but CUDA projects
> fail to properly compile under VS2017 as the compiler/linker fail to find
> tools on the path setup by CMake. I believe this is bug/incompatibly of the
> CMake FindCUDA module with VS2017.
>
> To reproduce the problem I am attaching a tiny project
>
> main.cu is a minimal CUDA example from the web
> CMakeLists.txt is a CMake file that leads to a successful build under VS2015
> and unsuccessful under VS2017
> Output VS2015 is the output from building the project under VS2015 (all
> targets built OK)
> Output VS2017 is the output from building the project under VS2015 (1 target
> OK one target fails)
>
> I have noticed also that oddly under VS2017 an "x64" and "main.dir"
> directories are created outside the build dir, and at the level of the
> source directory.
>
> I thought of reporting this to the list, and any help is welcome,
>
> Thank you and Best Regards,
>
> Andrea
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Possible bug/incompatibility FindCUDA with Visual Studio 2017

2017-08-10 Thread Andrea Borsic 

Hi All,

I am working on this platform:

 * Windows 10 64bit
 * Visual Studio 2015 Community Edition
 * Visual Studio 2017 Community Edition
 * CUDA 8.0
 * CMake 3.9

I am in the middle of switching from VS2015 to VS2017, but CUDA projects 
fail to properly compile under VS2017 as the compiler/linker fail to 
find tools on the path setup by CMake. I believe this is 
bug/incompatibly of the CMake FindCUDA module with VS2017.


To reproduce the problem I am attaching a tiny project

 * main.cu is a minimal CUDA example from the web
 * CMakeLists.txt is a CMake file that leads to a successful build
   under VS2015 and unsuccessful under VS2017
 * Output VS2015 is the output from building the project under VS2015
   (all targets built OK)
 * Output VS2017 is the output from building the project under VS2015
   (1 target OK one target fails)

I have noticed also that oddly under VS2017 an "x64" and "main.dir" 
directories are created outside the build dir, and at the level of the 
source directory.


I thought of reporting this to the list, and any help is welcome,

Thank you and Best Regards,

Andrea

PROJECT (Test)

CMAKE_MINIMUM_REQUIRED(VERSION 3.1)

FIND_PACKAGE(CUDA REQUIRED)

SET(CUDA_NVCC_FLAGS "-arch=sm_35" CACHE STRING "nvcc flags" FORCE)

CUDA_ADD_EXECUTABLE(main main.cu)


#include 

//
// Nearly minimal CUDA example.
// Compile with:
//
// nvcc -o example example.cu
//

#define N 1000

//
// A function marked __global__
// runs on the GPU but can be called from
// the CPU.
//
// This function multiplies the elements of an array
// of ints by 2.
//
// The entire computation can be thought of as running
// with one thread per array element with blockIdx.x
// identifying the thread.
//
// The comparison i>>(da, db);

//
// Copy output array from GPU back to CPU.
//
cudaMemcpy(hb, db, N*sizeof(int), cudaMemcpyDeviceToHost);

for (int i = 0; i-- Build started: Project: ZERO_CHECK, Configuration: Debug x64 --
1>  Checking Build System
1>  CMake does not need to re-run because 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp is up-to-date.
2>-- Build started: Project: main, Configuration: Debug x64 --
2>  Building NVCC (Device) object 
CMakeFiles/main.dir/Debug/main_generated_main.cu.obj
2>  main.cu
2>  main.cu
2>  Building Custom Rule D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test 
Cmake VS2017/src/CMakeLists.txt
2>  CMake is re-running because 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp is out-of-date.
2>the file 'D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/main.dir/main_generated_main.cu.obj.depend'
2>is newer than 'D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/CMakeFiles/generate.stamp.depend'
2>result='-1'
2>  -- Configuring done
2>  -- Generating done
2>  -- Build files have been written to: 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8
2> Creating library D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test 
Cmake VS2017/build_win64_vs2015_cuda8/Debug/main.lib and object 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/Debug/main.exp
2>  main.vcxproj -> D:\Dropbox\NES_Projects_Technical\Active\HP-EIT\Test Cmake 
VS2017\build_win64_vs2015_cuda8\Debug\main.exe
2>  main.vcxproj -> D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2015_cuda8/Debug/main.pdb (Full PDB)
3>-- Skipped Build: Project: ALL_BUILD, Configuration: Debug x64 --
3>Project not selected to build for this solution configuration 
== Build: 2 succeeded, 0 failed, 0 up-to-date, 1 skipped ==1>-- Build started: Project: ZERO_CHECK, Configuration: Debug x64 --
1>Checking Build System
1>CMake does not need to re-run because 
D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake 
VS2017/build_win64_vs2017_cuda8/CMakeFiles/generate.stamp is up-to-date.
2>-- Build started: Project: main, Configuration: Debug x64 --
2>Building NVCC (Device) object 
CMakeFiles/main.dir/Debug/main_generated_main.cu.obj
2>Failed to run C:/Program Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/bin (The system cannot find the file specified.
2>
2>).
2>CMake Error at main_generated_main.cu.obj.Debug.cmake:222 (message):
2>  Error generating D:/Dropbox/NES_Projects_Technical/Active/HP-EIT/Test Cmake
2>  
VS2017/build_win64_vs2017_cuda8/CMakeFiles/main.dir//Debug/main_generated_main.cu.obj
2>
2>
2>C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5):
 error MSB6006: