Re: [PATCH 3/3] rust: generate bindings via cbindgen

From: Ezekiel Newren <ezekielnewren@gmail.com>
Date: Oct 31, 2025, 23:36 UTC
Message-ID: <CAH=ZcbCq98m-yBcpoQG=iVN9EgRJrpjSWMq0QESs-1xSdRQu6Q@mail.gmail.com>
In-Reply-To: <aQM0_6uRZcQYfO8R@pks.im>

On Thu, Oct 30, 2025 at 3:51 AM Patrick Steinhardt <ps@pks.im> wrote:

Show 44 quoted lines

>
> On Mon, Oct 27, 2025 at 09:14:51PM +0000, brian m. carlson wrote:
> > On 2025-10-27 at 20:35:59, Ezekiel Newren wrote:
> > > On Fri, Oct 24, 2025 at 12:37 AM Patrick Steinhardt <ps@pks.im> wrote:
> > > > > cbindgen is a Rust crate and it should be specified in the Cargo.toml
> > > > > under [build-dependencies] block.
> > > >
> > > > What is the benefit for us? The generated code is not a dependency of
> > > > the Rust code, and neither do we use it via "build.rs". And if we use
> > > > cbindgen via "Cargo.toml" we'd be forced to build it first, which slows
> > > > down our CI jobs.
> > > >
> > > > Please let me know in case I miss any reasons to have it in our build
> > > > dependencies instead.
> > >
> > > You're targeting a very old version of Rust (1.49). I'm not even sure
> > > that cbindgen will work with a version that old, but if it does then
> > > we should use it in build.rs to make sure we're not using any features
> > > of cbindgen that aren't available until later versions. If we use
> > > cbindgen that is packaged with the platform then we can't precisely
> > > control which version of cbindgen is being used. This is a matter of
> > > reproducibility. There may be platforms that can compile Rust, but
> > > can't generate C header files via cbindgen because cbindgen hard codes
> > > that a certain minimum Rust version is required in its own Cargo.toml
> > > file.
> >
> > Yes, I agree with this.  Not all systems have cbindgen and it's not
> > guaranteed that the system's cbindgen will work with the version of Rust
> > that you want to target or that's being used to compile.
>
> Okay. In that case the question to me is how to drive cbindgen from our
> Makefile and from Meson if it's going to be invoked via "build.rs". It
> doesn't make much sense from my PoV to make generation of the C headers
> depend on building the complete Rust library. Doubly so because we'd now
> have a chicken-and-egg problem:
>
>   1. To build libgit.a we need to have the C interop header.
>
>   2. To build the C interop header we need to build the Rust library.
>
>   3. The Rust library depends on libgit.a.
>
> So am I missing anything obvious here for how to declare cbindgen in our
> "Cargo.toml" file and invoke it directly from our other build systems?

You would need a separate crate whose only job is to generate the header files and then Makefile or Meson can be invoked. But since we only have a single crate we can't do that.

As to why version 1.63.0 it's because of Debian [1]. "Our discussed plan is to support the version in Debian stable, plus a year. So we'd be supporting 1.63.0 for a year after trixie's release." - Brian M. Carlson

Rust version 1.49 can't use cbindgen newer than 0.1.0 (the latest is 0.29.2). Any cbindgen version newer than 0.1.0 requires a minimum of Rust 1.68.0. The way that I got cbindgen to work with version 1.63.0 is that I overrode cbindgen's dependencies in Cargo.toml. That hack only works so far because the older the Rust version the less likely older and older sub dependencies will work.

Since you're worried about build times I think that cbindgen should be in its own crate whose only job is to generate the header files and then have the subsequent CI jobs copy in those generated header files. For local development cargo will need to be invoked first to generate the header files and then Makefile or Meson can be invoked. If we put cbindgen into its own crate then we won't have a chicken-and-egg problem. That's why we need to convert to a cargo workspace in this patch series or before. It cannot come after.

[1]  https://lore.kernel.org/git/aHlp1joMwexLZAAb@fruit.crustytoothpaste.net/