Skip to content

Allow windows-targets to use the raw-dylib feature on newer rust versions by default #3494

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

Closed
silverstillisntgold opened this issue Feb 18, 2025 · 1 comment
Labels
question Further information is requested

Comments

@silverstillisntgold
Copy link

Suggestion

Rust 1.71 fully stabilized the raw-dylib feature. Currently, windows-targets will only use this feature when the windows_raw_dylib build flag is set, but I suspect most consumers of windows-targets are using downstream crates and are probably never going to go through the docs to see that this flag should be set on systems with newer rust versions. And it's not realistic to expect them to, I only happened to discover this behavior after stumbling across a random closed issue in a crate that uses windows-targets. Ideally, linking would always be done through raw-dylib when any rustc version supporting it is available.

My understanding is that this should be trivial to do with a simple build script to enable windows_raw_dylib when the rustc version is new enough. This would increase the work cargo has to do, but would also remove the need for linking against the provided static libraries, which should be a net win in compile times and binary sizes.

If this were to be done, would there be a need to provide some other config flag for users to disable the use of raw-dylib? Or is it generally better to use it if it's available? Maybe there's a benefit to bringing in the libraries that I'm unaware of.

@silverstillisntgold silverstillisntgold added the enhancement New feature or request label Feb 18, 2025
@kennykerr
Copy link
Collaborator

The windows-link crate #3450 has been introduced to address this issue. It should be released soon and all new code generation will use this by default.

@kennykerr kennykerr added question Further information is requested and removed enhancement New feature or request labels Feb 19, 2025
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

2 participants