[CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh.
Brian Davis
bitminer at gmail.com
Wed Aug 15 12:30:26 EDT 2018
So here's some more odd bits. Due to CMake (originally I only wanted to
upgrade VS) I have now entered the version upgrade cascade and upgraded to
cuda 9.0 (yes the one with 4 patches, but the only one that works
TensorFlow on windows due to cuDNN.dll... sigh) in hopes to get VS2017 to
work (hey why not right) and while I am at it why not upgrade CMake to
3.12.1 (latest) surely that will work like a charm. So lets go through
the config chart:
using CMake 3.12.1 (delete cache each time / start from scratch)
Configure -> VS 2013 -> cuda=9.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project
I get:
The CXX compiler identification is MSVC 18.0.31101.0
The CUDA compiler identification is NVIDIA 9.0.176
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v9.0/bin/nvcc.exe
Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v9.0/bin/nvcc.exe -- works
Detecting CUDA compiler ABI info
Detecting CUDA compiler ABI info - done
Found OpenGL: opengl32
FUORO4D_UTILITY_LIB_DEBUG =
C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib
and starts VS 2017 (now mind you *some* of those projects are loaded with
include_external_msproject (yeah I am guessing people may start to see the
problem here so loading the correct version of VS may well be important.)
and as such will be mixed mode cuda 8/9 surly to be a hoot in the future if
that path were continued.
so it successfully generates and loads something I cannot use at least
without resorting back to my .bat scripts with env vars set to load VS2013
So hey lets switch back to 8.0
Configure -> VS 2013 -> cuda=8.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project
The CXX compiler identification is MSVC 18.0.31101.0
The CUDA compiler identification is NVIDIA 8.0.60
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/x86_amd64/cl.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v8.0/bin/nvcc.exe
Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v8.0/bin/nvcc.exe -- works
Detecting CUDA compiler ABI info
Detecting CUDA compiler ABI info - done
Found OpenGL: opengl32
FUORO4D_UTILITY_LIB_DEBUG =
C:/projects/4DRTProto/4DRTProto/build/x64/Debug/Libraries/4DFUtilities.lib
Configuring done
VS2017 loads again and complains about one or more project files were not
loaded correctly. No surprise there.
Configure -> VS 2017 -> cuda=8.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project
Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
The CXX compiler identification is MSVC 19.14.26433.0
The CUDA compiler identification is unknown
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
CMake Error at CMakeLists.txt:14 (PROJECT):
No CMAKE_CUDA_COMPILER could be found.
Hmm that ain't never going to work. I installed 9.0 after VS2017 install
however.
Configure -> VS 2017 -> cuda=9.0 in (optional toolset to use (argument to
-T)) ->Generate -> Open Project
Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
The CXX compiler identification is MSVC 19.14.26433.0
The CUDA compiler identification is unknown
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
CMake Error at CMakeLists.txt:14 (PROJECT):
No CMAKE_CUDA_COMPILER could be found.
Ditto for that attempt
Configure -> VS 2017 -> leave blank in desperate hope CMake will figure it
out in (optional toolset to use (argument to -T)) ->Generate -> Open
Project
Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
The CXX compiler identification is MSVC 19.14.26433.0
The CUDA compiler identification is unknown
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x64/cl.exe --
works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
CMake Error at CMakeLists.txt:14 (PROJECT):
No CMAKE_CUDA_COMPILER could be found.
Ditto for that attempt
Aces! This sure is awesome.
On Wed, Aug 15, 2018 at 10:45 AM, Brian Davis <bitminer at gmail.com> wrote:
> Yes I know all about the bit about having to reinstall CUDA (been using it
> since the 2.0 days) for 2017 (using VS since 2005).... if only I could get
> CMake to call VS2013... ya know the version that already has cuda 8.0
> installed and configured and the extensions from C:\Program Files\NVIDIA
> GPU Computing Toolkit\CUDA\v8.0\extras\visual_studio_integration\MSBuildExtensions
> that get installed
>
> Can CMake defer to what the user ultimately wants? .. say the correct
> version of VS. I mean that is what I thought I specified.
>
> I had thought when I upgraded to 3.8/3.9 or whatever at the time that ...
> Oh great they now have an open project button... .maybe that will allow me
> to not have to generate .bat scripts to load VS (mind you my .bat script
> generation in CMake could actually tell me which correct version to load so
> these kinds of things are possible) with the env vars I set and set them in
> CMake and have CMake load VS (again correct version) with said env. It
> worked like a charm... well for a while anyway as it does with anything in
> the tech world. I certainly feel like I have upgraded.
>
>
> On Wed, Aug 15, 2018 at 9:48 AM, Robert Maynard <
> robert.maynard at kitware.com> wrote:
>
>> > cannot find CUDA likely as CUDA was not installed after 2017
>>
>> The CUDA language support requires the CUDA MSBUILD extensions, which
>> will require you to run the CUDA installer again ( it only installs
>> the msbuild extensions for versions that are currently installed ).
>>
>> > I would like it to load 2013 after being told to generate Visual
>> Studio 2013 project files.
>>
>> As Hendrik stated CMake defers to the windows shell/explorer for
>> opening solution files.
>> On Tue, Aug 14, 2018 at 7:27 PM Brian Davis <bitminer at gmail.com> wrote:
>> >
>> >
>> > It also cannot find CUDA likely as CUDA was not installed after 2017.
>> I would like it to load 2013 after being told to generate Visual Studio
>> 2013 project files. Is this difficult to ask fo Kitware? I am sure there
>> are certainly some shenanigans like path or VS2017 hooking calls to 2013
>> tools or the like all of which I am sure make sens to a cubite in the
>> bowels of the MS machine. VS loaded 2017 and vs 2013 proj files then
>> promptly had problems searching files, compiling stale targets and the
>> like. So while VS2017 make "hook" 2013 tools it certainly can't do any
>> thing useful with them IME. Is there a Meta buld tool (goop generator)
>> that will build goop for a target goop reader then call said target goop
>> reader (of correct specified version) to read goop and compile my code?
>> sigh.
>> >
>> > --
>> >
>> > 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:
>> > https://cmake.org/mailman/listinfo/cmake
>>
>
>
>
> --
> Brian J. Davis
>
--
Brian J. Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180815/2a2de038/attachment-0001.html>
More information about the CMake
mailing list