On 9/4/25 7:39 PM, Ezekiel Newren wrote: > On Thu, Sep 4, 2025 at 8:27 AM Patrick Steinhardt <ps@xxxxxx> 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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
