Rustbuild requires vcvars for windows msvc

[retep998]

Windows 10 64-bit with several versions of Visual Studio installed.

C:\msys64\home\Peter\rust [please-be-robust-already ≡]> python.exe .\src\bootstrap\bootstrap.py
thread '<main>' panicked at 'couldn't determine visual studio generator', C:\Users\Peter\.cargo\registry\src\github.jparrowsec.cn-1ecc6299db9ec823\cmake-0.1.17\src\lib.rs:382
stack backtrace:
   0:     0x7ff6f805c482 - std::rt::lang_start::h77a570d0150f3bb2
   1:     0x7ff6f805ba6d - std::rt::lang_start::h77a570d0150f3bb2
   2:     0x7ff6f8041775 - std::panicking::rust_panic_with_hook::h86decb25b2d9b2e0
   3:     0x7ff6f7fde944 - begin_panic<&str>
                        at C:\msys64\home\Peter\src\libstd\panicking.rs:328
   4:     0x7ff6f7fe15f9 - visual_studio_generator
                        at C:\msys64\home\Peter\rust\<std macros>:3
   5:     0x7ff6f7fd30cf - build
                        at C:\Users\Peter\.cargo\registry\src\github.jparrowsec.cn-1ecc6299db9ec823\cmake-0.1.17\src\lib.rs:276
   6:     0x7ff6f7efc997 - llvm
                        at C:\msys64\home\Peter\rust\src\bootstrap\build\native.rs:113
   7:     0x7ff6f7ee978b - build
                        at C:\msys64\home\Peter\rust\src\bootstrap\build\mod.rs:230
   8:     0x7ff6f7ee12ba - main
                        at C:\msys64\home\Peter\rust\src\bootstrap\main.rs:48
   9:     0x7ff6f805b46c - std::rt::lang_start::h77a570d0150f3bb2
  10:     0x7ff6f80616c1 - _rust_maybe_catch_panic
  11:     0x7ff6f805b1a4 - std::rt::lang_start::h77a570d0150f3bb2
  12:     0x7ff6f7eee9f9 - main
  13:     0x7ff6f8068bef - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255
  14:     0x7ffe8ad78101 - BaseThreadInitThunk

According to this comment by @alexcrichton, having to use vcvars to build Rust is a bug, so I have opened this issue.

[alexcrichton]

The relevant function for detecting the visual studio generator is located here, and it's pretty simple in terms of trying to detect what it should pass. Perhaps there's a better method of determining what the cmake generator should be? This may also be a case where it's only broken on some installations (perhaps more recent ones?) rather than older ones.

[retep998]

I think the problem might be that gcc tries to find whatever the highest msvc version in the registry is, while cmake is hardcoded to only support two specific versions of msvc. Since I have Visual Studio 15.0 installed, gcc is likely picking that as the highest msvc version and then cmake doesn't know what to do with that. I think it would be more useful if gcc could return a selection of visual studio versions and the downstream crate, such as cmake, could pick which one it wants.

// TODO: need a better way of scraping the VS install...

[alexcrichton]

One thing that may be helpful to resolve this is some more information about your local setup as well. For example what path is returned that cmake-rs is taking a look at? What's the correct generator for Visual Studio 2015 in this case?

[retep998]

Some("C:\\Program Files (x86)\\Microsoft Visual Studio 15.0\\VC/bin\\amd64\\cl.exe")
Meanwhile the latest version of CMake 3.6 only goes up to Visual Studio 14.0.

[alexcrichton]

Hm so that is, if only Visual Studio 2015 is installed, then CMake can't actually generate build files?

[retep998]

Well, 14.0 is VS 2015 which is fine, while 15.0 is the new preview version of Visual Studio which CMake doesn't support yet.

[alexcrichton]

Ok, so you're thinking that cmake-rs understand a list of generators, and it tries to find all installations as well. If any generator matches any installation, it'll do that, but otherwise it'll give an error?

[retep998]

@alexcrichton Yes, I think that would be a superior solution to the current system.

[alexcrichton]

Unfortunately that suffers the problem of disagreement among tools of which version of Visual Studio to use. In that case gcc-rs might pick the highest version whereas cmake-rs would pick a lower version, and presumably the two are not interoperable, right?

[retep998]

Statically linking code compiled with different versions of MSVC can cause issues, yes. So there'd have to be some way for everything to agree on which version of MSVC to use. Fortunately you can get around it by just invoking vcvars, although that doesn't work in cross compiling situations because either host code or target code would end up using the wrong linker.