Missing arch handling in Visual Studio generators
While looking through the code I observed that the visual_studio_generator function sets an incorrect generator for the VS "15.0" version(I was using CMake 3.8-rc and observed that it has a different generator).
Here is the list of generators that 3.8.0 reports on this Windows machine:
The following generators are available on this platform:
Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
Optional [arch] can be "Win64" or "IA64".
Visual Studio 9 2008 [arch] = Generates Visual Studio 2008 project files.
Optional [arch] can be "Win64" or "IA64".
Visual Studio 8 2005 [arch] = Generates Visual Studio 2005 project files.
Optional [arch] can be "Win64".
Visual Studio 7 .NET 2003 = Deprecated. Generates Visual Studio .NET
2003 project files.
Borland Makefiles = Generates Borland makefiles.
NMake Makefiles = Generates NMake makefiles.
NMake Makefiles JOM = Generates JOM makefiles.
Green Hills MULTI = Generates Green Hills MULTI files
(experimental, work-in-progress).
MSYS Makefiles = Generates MSYS makefiles.
MinGW Makefiles = Generates a make file for use with
mingw32-make.
Unix Makefiles = Generates standard UNIX makefiles.
Ninja = Generates build.ninja files.
Watcom WMake = Generates Watcom WMake makefiles.
CodeBlocks - MinGW Makefiles = Generates CodeBlocks project files.
CodeBlocks - NMake Makefiles = Generates CodeBlocks project files.
CodeBlocks - NMake Makefiles JOM
= Generates CodeBlocks project files.
CodeBlocks - Ninja = Generates CodeBlocks project files.
CodeBlocks - Unix Makefiles = Generates CodeBlocks project files.
CodeLite - MinGW Makefiles = Generates CodeLite project files.
CodeLite - NMake Makefiles = Generates CodeLite project files.
CodeLite - Ninja = Generates CodeLite project files.
CodeLite - Unix Makefiles = Generates CodeLite project files.
Sublime Text 2 - MinGW Makefiles
= Generates Sublime Text 2 project files.
Sublime Text 2 - NMake Makefiles
= Generates Sublime Text 2 project files.
Sublime Text 2 - Ninja = Generates Sublime Text 2 project files.
Sublime Text 2 - Unix Makefiles
= Generates Sublime Text 2 project files.
Kate - MinGW Makefiles = Generates Kate project files.
Kate - NMake Makefiles = Generates Kate project files.
Kate - Ninja = Generates Kate project files.
Kate - Unix Makefiles = Generates Kate project files.
Eclipse CDT4 - NMake Makefiles
= Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - MinGW Makefiles
= Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
Thanks for the report! Is the fix here just to add the year?
Yes. I have access to a Windows machine at work, I'll reconfirm today if this fixes the issue(or if it is necessary at all).
I see one more issue. https://github.com/alexcrichton/cmake-rs/blob/master/src/lib.rs#L516 : it handles only traditional PC architectures and panics otherwise. The CMake help indicates that you could pass "ARM" as an architecture.
I just tried it and seems like passing Visual Studio 15 to CMake is also ok(in messages, the generator is transformed into Visual Studio 15 2017).
The issue with ARM still remains.
I get an error that there is no install.vcxproj but that's probably because the project I am trying on, doesn't have an install target(I don't know what kind of file is generated for the install target on MSBuild).
At least for the default target, Makefiles have all and MSBuild has ALL_BUILD, so that's why I am not sure what kind of target would be generated for install.
Ah yeah I'm fine adding support for ARM as well, although we don't have an arm windows target upstream yet in rust-lang/rust so it wouldn't be very usable today.