-
Notifications
You must be signed in to change notification settings - Fork 442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support getting Windows SDK from the environment #625
Comments
Are you interested in staying on the latest compiler version and changing the SDK it uses (So trying to use the VS 2019 msvc with 2017's SDK for example), if that's even possible, or would changing the used compiler and tools to the other VS installation satisfy your requirements? I think cc-rs just uses whatever SDK the compiler it finds uses by default. Glancing at the cc-rs code it looks like it only uses 3 pieces of information from vswhere at the moment: I think installation_name is only used here https://github.com/alexcrichton/cc-rs/blob/e643cc14c497007a73fbf347d295a15cde6cd70f/src/windows_registry.rs#L254-L270 to determine version name, so really it's 2 pieces of information: The version and the installation_path. installation_path for my 2019 vswhere is vcvarsall.bat seems to put the equivalent path to "installation_path" from vswhere in the For the version, vswhere with 2019 for me gives I don't see this version string in any environment variables set by vcvarsall. We could maybe do a string contains for 2019/17/etc on the install dir, but I don't know how brittle that is if VS is installed in a non default location (Is that possible?). Here's everything I see in a vcvarsall with 19 and 261 in case anyone else has any ideas: |
Sorry, I should have explained better. The background for this is rust-lang/rust#88796 where, at the time, using the newer Windows SDK 10.0.20348 broke whereas the older 10.0.19041 worked. I thought it would be good for cc-rs to be able to support specifying/overriding the lib version somehow. Getting the SDK is a separate step to getting the VC install and is implemented in fn add_sdks(). The version is sorted "asciibetically" and only the latest is returned: |
Thanks for the clarification, sent a pull request. |
One thing that was brought up recently with the Windows CI's update was a desire to stay with a particular version of the Windows SDK even when a newer version is avaliable. Currently
cc
always gets the latest with no easy way (as far as I'm aware) to override it. Usually this works out fine but not always.It would be great if it could default to using the environment before falling back to finding the latest. Possibly relevant environment variables (set by
vcvarsall.bat
or developer powershell):WindowsSDK_ExecutablePath_x64
WindowsSDK_ExecutablePath_x86
WindowsSdkBinPath
WindowsSdkDir
WindowsSDKLibVersion
WindowsSdkVerBinPath
WindowsSDKVersion
I don't have the bandwidth to test a fix for this atm, so if anyone else wants to look into it I'd appreciate it.
The text was updated successfully, but these errors were encountered: