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? Bart