Subject: Re: [PATCH RFC 2/3] rust: implement a test balloon via the "varint" subsystem

From: Eli Schwartz <[email-masked]>
Date: Thu, 4 Sep 2025 22:00:45 -0400

On 9/4/25 7:39 PM, Ezekiel Newren wrote:
> On Thu, Sep 4, 2025 at 8:27 AM Patrick Steinhardt <[email-masked]> wrote:
>> Implement a trivial test balloon for our Rust build infrastructure by
>> reimplementing the "varint.c" subsystem in Rust. This subsystem is
>> chosen because it is trivial to convert and because it doesn't have any
>> dependencies to other components of Git.
> 
> Huh, I thought Meson couldn't run Rust tests. It's refreshing to see
> someone else try a different approach on bringing Rust to Git.
> 
> There are a few reasons why I picked Cargo instead of Meson to build Rust:
>   1. Needs to work with make.

If the rust code is defined as a crate, meson can auto-import that crate
via parsing Cargo.toml, so perhaps this can simply be done by creating a

[lib]
crate-type = 'cdylib'

and... importing it as a meson subproject. You'd be able to build it
with cargo build, if you really want to (and the Makefile may have to)
but Meson would not be limited to this.

>   2. I've heard that using crates in Meson is quite painful.

This is specific to build.rs, and it is "difficult" in the sense that
meson cannot compile build.rs into an executable depending on other crates.

Compiling it into an executable depending on other crates is a
prerequisite for running it and parsing its stdout into a list of
defines (rust calls them --cfg) to pass as command line flags for the
real build target.

Meson has official guidance for doing that work in-process by writing a
"plugin" meson.build:

https://mesonbuild.com/Wrap-dependency-system-manual.html#cargo-wraps

build.rs is not something which any crate likes to have anyway. Most
crates therefore don't. And don't have any problem being used by meson.

>   3. My understanding is that someday in the distant future Rust will
> supplant C in Git.

And you will want a build system that understands both compiling rust,
and installing files in general (cargo cannot do this) and installing a
quite wide variety of data files (implicitly the previous point means
cargo cannot do this either).

Who knows? Maybe in the "distant" future, Meson will have even more
additional support for Rust. I think I may have heard a rumor that Meson
is open source, so contributors will probably be welcome. I also heard
another rumor that QEMU has been contributing a lot to this, and Gnome
and Mesa as well.

If it's all part of the distant future anyway, we can *certainly* try to
help shape the future to fit our needs, and experiment with different
ways to achieve that.

...

BTW: running tests with cargo is a genuine nightmare hellscape. As a
linux distro packager, I don't know what is wrong with cargo but I sure
as heck know that if I run `cargo build` followed by `cargo test`, the
resulting binary, if installed, will have incorrect behavior.

https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-util/ruff?id=f10d64828e9c33b2a1951c9a0e1fa84e4a736875

Meson has sane behavior here, because two completely different build
targets (a program and a unittest) don't create the *same* file.

I am very nervous about trusting cargo for predictable behavior.

>   3. The IDE RustRover only understands Cargo.

Since Meson 0.64 we generate the rust-analyzer official format for
integration:

https://mesonbuild.com/Rust.html#use-with-rustanalyzer

We're very much open to ideas about how to improve this but my
understanding was that rust itself expects you to use this special file
-- why doesn't RustRover use it?

Is RustRover (a very specific thirdparty IDE) a dealbreaker, one way or
another?

> As I mentioned in another thread: The reason why I made Rust a hard
> dependency is because it's easier to develop and talk about that way.
> I'm open to suggestions on how to make Rust optional.

-- 
Eli Schwartz