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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Oct 9, 2023 at 5:21 PM Erik Schilling <erik.schilling@xxxxxxxxxx> wrote:
>
> On Mon Oct 9, 2023 at 4:39 PM CEST, Manos Pitsidianakis wrote:
> > On Mon, 09 Oct 2023 17:32, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> > >I'm Cc'ing Phil Howard who's the developer behind the Python bindings
> > >work.
>
> Hi!
>
> > >
> > >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.
>
> Right. One can use cc, there also seems to be a somewhat popular crate
> that allows calling autotools: https://crates.io/crates/autotools.
>
> That said. I am not sure if I like listing all the sources and defining
> the build process manually again. It feels like we duplicate what the
> existing build system already does for us and no longer have a single
> source of truth...
>
> Taking a look at the openssl build code [1] I also see all the target
> and environment specific hacks that I feared about... I guess it won't
> be as bad for libgpiod, but I guess it might be a painful way to figure
> out whether that is true.
>
> I have seen similar things happening when cmake projects attempted to
> vendor in external dependencies and are not a huge fan of marrying to
> different worlds together like this.
>
> That said. I am completely supportive to the idea of exploring static
> linking for the Rust bindings. I am just sceptical that doing that by
> default will make things more simple for consumers on the long run.
>
> [1] https://github.com/alexcrichton/openssl-src-rs/blob/main/src/lib.rs
>
> >
> > >
> > >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.
>
> Thats true for attempting to support different versions of the C lib
> (and it is what I suggest in this series). However, the recent release
> became necessary to a bug in the Rust bindings, not in the C lib. So a
> stable branch could still make sense. But hopefully, we would only need
> it increasingly rarely in the future.
>
> Overall I still think what I suggest in this patch + maybe exploring
> optional static linking is the simplest path. I mostly suggested this as
> an alternative since I felt resistance to my suggestion :)
>
> - Erik
>

Fair enough, I applied patch 1/2.

Bart