On Wed Aug 27, 2025 at 3:57 PM CEST, Bartosz Golaszewski wrote: > On Wed, Aug 27, 2025 at 8:36 AM Erik Schilling <erik@xxxxxxxxxxxx> wrote: >> >> On Tue Aug 26, 2025 at 8:07 PM CEST, Bartosz Golaszewski wrote: >> > On Mon, Aug 18, 2025 at 9:26 AM Erik Schilling <erik@xxxxxxxxxxxx> wrote: >> >> >> >> On Fri Aug 15, 2025 at 10:57 AM CEST, Bartosz Golaszewski wrote: >> >> > The libgpiod rust bindings interface has stayed quite stable over the >> >> > last months so it's time for it to stop being a v0.x release and become >> >> > officially carved in stone. Bump dependencies to the most recent versions >> >> > available, fix some issues and then bump versions of the crates ahead of >> >> > the official release. >> >> > >> >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >> >> > --- >> >> > Changes in v2: >> >> > - drop the patch bumping the minimum required rust version >> >> > - loosen the requirements on the dependency versions: specify only the >> >> > major number for stable crates and the major.minor for unstable ones >> >> > - Link to v1: https://lore.kernel.org/r/20250812-rust-1-0-0-release-v1-0-372d698f23e8@xxxxxxxxxx >> >> > >> >> > --- >> >> > Bartosz Golaszewski (9): >> >> > bindings: rust: make Buffer::read_edge_events() lifetimes more explicit >> >> > bindings: rust: add missing unsafe block ahead of rust version bump >> >> > bindings: rust: update bindgen dependency >> >> > bindings: rust: update errno dependency >> >> > bindings: rust: update cc dependency >> >> > bindings: rust: update system-deps dependency >> >> > bindings: rust: update thiserror dependency >> >> > bindings: rust: update intmap dependency >> >> > bindings: rust: update crate versions to v1.0.0 >> >> > >> >> > bindings/rust/gpiosim-sys/Cargo.toml | 8 ++++---- >> >> > bindings/rust/gpiosim-sys/build.rs | 2 +- >> >> > bindings/rust/libgpiod-sys/Cargo.toml | 6 +++--- >> >> > bindings/rust/libgpiod-sys/build.rs | 6 +++--- >> >> > bindings/rust/libgpiod/Cargo.toml | 10 +++++----- >> >> > bindings/rust/libgpiod/src/event_buffer.rs | 2 +- >> >> > bindings/rust/libgpiod/src/lib.rs | 4 ++-- >> >> > bindings/rust/libgpiod/src/line_config.rs | 2 +- >> >> > bindings/rust/libgpiod/src/line_info.rs | 2 +- >> >> > bindings/rust/libgpiod/src/line_request.rs | 4 ++-- >> >> > 10 files changed, 23 insertions(+), 23 deletions(-) >> >> > --- >> >> > base-commit: cd32f27dd550753488bff4918aef4e230ce01512 >> >> > change-id: 20250811-rust-1-0-0-release-65342607040e >> >> > >> >> > Best regards, >> >> > -- >> >> > Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >> >> >> >> Trying to build with the 1.60 that we claim as lower floor gives me: >> >> >> >> > cargo +1.60 build >> >> [...] >> >> error: package `bindgen v0.72.0` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.60.0 >> >> >> >> With 1.70 I get: >> >> >> >> ~/projects/libgpiod/bindings/rust (master)> cargo +1.70 build >> >> [...] >> >> error: package `system-deps v7.0.5` cannot be built because it requires rustc 1.78.0 or newer, while the currently active rustc version is 1.70.0 >> >> >> >> >> >> 1.78 builds fine (when having cfg-expr pinned to a pre-2024-edition >> >> version). >> >> >> >> So we will need to bump the MSRV to at least 1.78. The critical path >> >> seems to be cfg-expr -> system-deps where cfg-expr seems to be extremely >> >> aggressive with updating it's MSRV... >> >> >> >> 1.78 with a release in May 2024 looks reasonable to me. >> >> >> >> Otherwise this looks good to me! >> >> >> >> - Erik >> >> >> > >> > Am I getting this right, should I bump min rust version to 1.78 but >> > leave the edition at 2021? >> >> Yes. The 2024 edition came with 1.85. So neither our libs nor we >> ourselves require that yet. But we _do_ require 1.78 with these changes >> now. >> >> > And what does "pinned to a pre 2024-edition" even mean? >> >> The latest cfg-expr version sets edition = "2024". It looks like that >> fails the Cargo.toml parse and the rust-version in the .toml does not >> work to restrict the automatic update. To fix that I had to set the >> version in the Cargo.lock file manually: >> >> cargo +1.78 update -p cfg-expr --precise 0.18.0 >> >> This was the last version before the bump to 2024 edition and 1.85 MSRV. >> >> We - as a library - do not have a .lock file. So cargo will try to use >> the latest and greatest. But a consumer of libgpiod will have such a >> .lock file and is still able to build libgpiod with these changes under >> 1.78. >> > > Will the user-experience be: build fails -> user needs to manually > downgrade cfg-expr in Cargo.lock -> build now succeeds? That doesn't > sound very convenient and I'm afraid people will just bounce right > off. Am I missing something? Hm. This only impacts people using older Rust versions. It requires the manual pinning of an old version, but allows them to use their Rust version. If we bump the MSRV then we lock them out altogether. So a "manual pinning" of versions seems like an improvement over "not supported at all". So it mostly makes an already misrable life slightly less miserable. Users of newer Rust versions won't be impacted by any of these problems and experience no down-sides. Does that make more sense? Aside: I found a somewhat related ticket on the cargo bug tracker and left a comment there: https://github.com/rust-lang/cargo/issues/15305#issuecomment-3232412629 - Erik