Re: [libgpiod][PATCH 0/2] bindings: rust: feature gate unreleased features

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

On Mon, 09 Oct 2023 17:32, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>I'm Cc'ing Phil Howard who's the developer behind the Python bindings 
>work.
>
>In Phil's WiP branch[1] that should soon be posted to this list the
>autotools flow is entirely omitted and building of the libgpiod C
>sources happens in setup.py directly. Can cargo compile C sources like
>that?

The rust compiler team maintains a library for that:

https://crates.io/crates/cc

You can find examples of it in use in many popular rust crates, like 
when building the openssl crate https://docs.rs/openssl/latest/openssl/ 
with the `vendored` feature, it uses the following build-time dependency 
to build the static librarie:

https://github.com/alexcrichton/openssl-src-rs/tree/main

There is no general need to put the vendoring code in a build-time 
dependency by the way, it can be done in in the bindings crate's 
build.rs as well.

>
>I'm not sure how that would work honestly. The stable branches in
>libgpiod are per libgpiod minor release. This doesn't map onto rust
>releases anymore with decoupled versioning. Maybe rust should get its
>own tags in the repo (on the master branch for major and minor
>releases) and its own stable branches?

In cases Rust crates want to support multiple releases, the usual route 
is to expose different bindings per release exposed via feature flags.

I can't say if that makes sense for libgpiod though, because I'm not 
familiar that much.

Manos