-
Notifications
You must be signed in to change notification settings - Fork 493
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
Add feature flags for Windows SDK versions #3247
Comments
Specifically for Rust's std use case, feature flags wouldn't be the best approach. It would really need to be an option in the |
This will require accurate upstream targeting information. SupportedOSPlatform is not currently stable/usable. |
Yes assuming we can stabilize the version metadata, I'd initially only make this available through It does however appear that there's not been much progress in stabilizing this metadata, so this may all be wishful thinking at present: |
Closing this issue until there's a resolution on metadata - let's keep the conversation going on the upstream issue: microsoft/win32metadata#738 |
Suggestion
It's fairly common for projects to set an older version of Windows as their "minimum supported version". However, this means that they must be careful which Windows APIs they use as not all APIs are available on all versions of Windows.
One way to verify that the APIs your project uses exist on a given version of Windows is to build against the SDK for that Windows version. However, this isn't always practical (projects may not control what software is on their CI machines and installing Windows SDKs is slow), causes other build issues (e.g., using Arm64EC requires the Windows 11 SDK) and doesn't help at all when using
raw-dylib
(as the Windows SDK import libraries aren't used). Even if a project is doing this, it would be nice to get clear errors during the Rust build rather than obscure linker failures.Instead, windows-rs could add feature flags that corresponded to the various Windows SDK versions, which would allow projects to select which set of APIs to make available at build time.
The text was updated successfully, but these errors were encountered: