-
-
Notifications
You must be signed in to change notification settings - Fork 753
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
Emit rustc-check-cfg for nightly #2235
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like there's some refactoring to do to make this more maintainable long-term but this looks fine for now.
@@ -104,6 +140,9 @@ fn main() { | |||
if version >= 0x1_01_01_00_0 { | |||
println!("cargo:rustc-cfg=ossl111"); | |||
} | |||
if version >= 0x1_01_01_04_0 { | |||
println!("cargo:rustc-cfg=ossl111d"); | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yuuuup.
TBH this feels motivating to find some way to deprecate and remove support for super old OpenSSL's. Most of this list is for stuff that there's no earthly reason to use. Not sure how to square that with semver + the need to have a single openssl-sys package though. |
Yeah. openssl-sys breaks are very rough ecosystem-wise, so I might say that an "if a tree falls in the forest" approach is best there. In the main openssl crate we can (and should, there are a ton of pent up breaks to make) do a bump. We should definitely drop 1.0.1 support. CentOS 7 EOLs in a month or two and I feel like that's probably a decent time to drop 1.0.2 support as well. |
In terms of openssl-sys, my best idea is:
End users still need a cutover point, but for most of the ecosystem they should be fine. |
There are a ton of crates that directly depend on openssl-sys that would need updating unfortunately: https://crates.io/crates/openssl-sys/reverse_dependencies |
Yeah, they'd at least be able to migrate incrementally (probably to
"supports both"). If they're unmaintained that'd be a problem though.
…On Sun, May 5, 2024, 11:58 AM Steven Fackler ***@***.***> wrote:
There are a ton of crates that directly depend on openssl-sys that would
need updating unfortunately:
https://crates.io/crates/openssl-sys/reverse_dependencies
—
Reply to this email directly, view it on GitHub
<#2235 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBCOPZFPCHFBUIN6PNLZAZJKFAVCNFSM6AAAAABHHYYNCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHA2TSOJVGE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
This may have been fixed, but at least for a while Cargo's version resolution didn't handle constraints like that very well - it would select the newest version even if that would cause two versions to be included in the crate graph. Probably worth some experimenting to see how things behave now. |
See https://doc.rust-lang.org/nightly/cargo/reference/build-scripts.html#rustc-check-cfg