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

["Erik Schilling" <erik.schilling@linaro.org>]

On Mon Oct 9, 2023 at 4:39 PM CEST, Manos Pitsidianakis wrote:
> 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.

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