Skip to content
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

Closed
dpaoliello opened this issue Sep 3, 2024 · 4 comments
Closed

Add feature flags for Windows SDK versions #3247

dpaoliello opened this issue Sep 3, 2024 · 4 comments
Labels
question Further information is requested

Comments

@dpaoliello
Copy link
Collaborator

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.

@ChrisDenton
Copy link
Collaborator

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 windows-bindgen crate (e.g. --api-version 10.0.10240) that errors if a function is used that isn't supported by the target version.

@riverar
Copy link
Collaborator

riverar commented Sep 3, 2024

This will require accurate upstream targeting information. SupportedOSPlatform is not currently stable/usable.

@kennykerr
Copy link
Collaborator

Yes assuming we can stabilize the version metadata, I'd initially only make this available through windows-bindgen as a filter/validator of sorts.

It does however appear that there's not been much progress in stabilizing this metadata, so this may all be wishful thinking at present:

microsoft/win32metadata#738

@kennykerr kennykerr added question Further information is requested and removed enhancement New feature or request labels Sep 3, 2024
@kennykerr
Copy link
Collaborator

Closing this issue until there's a resolution on metadata - let's keep the conversation going on the upstream issue: microsoft/win32metadata#738

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants