search

rust-lang / cc-rs

Rust library for build scripts to compile C/C++ code into a Rust library
https://docs.rs/cc
Apache License 2.0
1.79k stars 434 forks source link

Release v1.0.106 bumped MSRV in a patch release #1144

Closed tnull closed 1 month ago

tnull commented 1 month ago

It seems the just-released v1.0.106 bumped the MSRV from 1.63 to 1.67 in a patch release.

Unfortunately this breaks our downstream MSRV builds, which depend on rustc 1.63 (currently shipped with Debian Bookworm).

I want to ask you to consider reverting the MSRV bump as it introduces issues for users downstream that need to support 'older' Rust version, especially since raising the MSRV seems to have happened only for a mere convenience feature in https://github.com/rust-lang/cc-rs/pull/1137

NobodyXu commented 1 month ago

Hello, sorry to hear that it breaks your build.

Is it possible for you to pin the cc version via Cargo.lock?

BTW cargo is working on a msrv-aware resolution feature to help this.

TheBlueMatt commented 1 month ago

Is it possible for you to pin the cc version via Cargo.lock?

For a library to support an MSRV, sadly, that's not an option. We could pin cc explicitly in the Cargo.toml, but that really sucks as it means any new features needed for new platforms cant work either.

There's also the issue of -Zbuild-std, which doesn't support Cargo.lock and is needed when building targeting apple platforms from Linux (which is, in turn, needed for practical reproducible builds, or at least I've never gotten them to work otherwise).

ChrisDenton commented 1 month ago

I don't think it's currently tenable for us to consistently maintain a 3+ year MSRV.

If using the Debian system rustc is absolutely necessary, note that they do also maintain a cc-rs package for this purpose.

NobodyXu commented 1 month ago

There's also the issue of -Zbuild-std, which doesn't support Cargo.lock

stdlib/rustc doesn't pin the version?

I was under the impression that stdlib/rustc pin to a specific cc version...

But if you are using -Zbuild-version, then it should be nightly compiler, unless you compiled the rustc with some special options to enable nightly options

TheBlueMatt commented 1 month ago

I don't think it's currently tenable for us to consistently maintain a 3+ year MSRV.

I mean that may well be the case, but (a) we could at least only change the MSRV if there's a compelling feature that cannot (practically) be shipped without changing the MSRV, and/or (b) change the minor (or major) version when that point is reached. At this point it seems like cc did just fine with a very old MSRV for a long time and until now hadn't found a feature that was work increasing it for even with a very low bar for doing so. Bumping that bar a bit would be much appreciated.

stdlib/rustc doesn't pin the version?

Sadly -Zbuild-std doesn't (to my knowledge) currently pin crate versions and pulls them from crates.io. Its a known limitation, AFAIU.

NobodyXu commented 1 month ago

If it is for x-lto, is there another way?

I.e. compile in docker, where the rustc 1.67 and clang uses the same LLVM version?

ChrisDenton commented 1 month ago

change the minor (or major) version when that point is reached

Others have tried this approach (treating it as a semver breaking change) but found it isn't really tenable. E.g. see the discussion on the API guidelines repo https://github.com/rust-lang/api-guidelines/discussions/231#discussioncomment-5864561

TheBlueMatt commented 1 month ago

Others have tried this approach (treating it as a semver breaking change) but found it isn't really tenable.

Major version maybe not but many other projects have no problem changing the minor version for MSRV changes? eg tokio does it and it lets tokio support the MSRV-limited versions for some time with security and important updates without being forced into a low MSRV forever.

If it is for x-lto, is there another way? I.e. compile in docker, where the rustc 1.67 and clang uses the same LLVM version?

I mean in principle yes, but that takes building an application from source from "just clone this repo, install rust and build" to "first build rust, including fetching a full version of docker or whatever, also build llvm and clang from source, etc", which is totally untenable.

NobodyXu commented 1 month ago

I'm ok with a 1.1.0 release, that sounds very reasonable

NobodyXu commented 1 month ago

I mean in principle yes, but that takes building an application from source from "just clone this repo, install rust and build" to "first build rust, including fetching a full version of docker or whatever, also build llvm and clang from source, etc", which is totally untenable.

Yeah that makes sense, for project that needs x-lto, I guess either you depend on debian stable, or maintain a Dockerfile officially with the same llvm version

Noratrieb commented 1 month ago

How does updating it in a minor release vs a patch release help you? I don't see a significant difference there.

TheBlueMatt commented 1 month ago

Its not a huge difference, no, either way we're stuck pinning cc in Cargo.toml explicitly which sucks, the only difference is assuming cc takes a stance like tokio where it can/does backport security and important bugfixes (or, for cc, possibly even new platform support where it doesn't require breaking MSRV for existing platforms) to the prior minor version. Of course my preferred outcome would be at least a policy of "dont bump MSRV unless you kinda have to", but I was just raising other options.

NobodyXu commented 1 month ago

A cyclical compilation error is found in #1146 , we would need to bump msrv to 1.70 to use std::sync::OnceLock to fix it.

workingjubilee commented 1 month ago

Its not a huge difference, no, either way we're stuck pinning cc in Cargo.toml explicitly which sucks, the only difference is assuming cc takes a stance like tokio where it can/does backport security and important bugfixes (or, for cc, possibly even new platform support where it doesn't require breaking MSRV for existing platforms) to the prior minor version.

I don't think that's happening for cc-rs. aiui tokio has professional support explicitly paid to work on tokio and adjacent problems.

TheBlueMatt commented 1 month ago

I don't think that's happening for cc-rs. aiui tokio has professional support explicitly paid to work on tokio and adjacent problems.

Of course I'm not purporting to mandate that some open source project takes on the same work as a funded one, but funding isn't the issue here - just go look at how often Tokio has to backport anything (and that's for a runtime network-facing dependency, not a compile-time one), it's very little of their total work volume, arguably almost nothing.

NobodyXu commented 1 month ago

@tnull @TheBlueMatt msrv is reverted to 1.63 in v1.1.3

tnull commented 1 month ago

@tnull @TheBlueMatt msrv is reverted to 1.63 in v1.1.3

Thank you for the swift reaction, much appreciated!

TheBlueMatt commented 1 month ago

Thank you so much!

NobodyXu commented 1 month ago

BTW, it looks like we will have to refrain MSRV bump until next debian stable release, which is probably going to happen in 2025 Aug-Oct with rust 1.79

Finger crossed it will come soonner