Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory
- From
Sam James <sam@gentoo.org>
- Date
- Sep 17, 2025, 12:07 UTC
- Message-ID
- <87plbpffk1.fsf@gentoo.org>
- In-Reply-To
- <aMk2mo5OHPNQi0PW@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 47 quoted lines
> On Mon, Sep 15, 2025 at 08:03:29PM -0600, Ezekiel Newren wrote: >> I am currently working on a patch series that makes Rust optional and >> addresses several concerns that this series does not: >> * Rust calling C: Makefile has no way to build or run Rust so it >> would have to call cargo test, but that doesn't work unless build.rs >> tells cargo where libgit.a is (among other things). >> * Build tooling alignment: My build_rust.sh is called by make and >> meson which eliminates defining how to build Rust in 2 places. >> * Cargo vs Meson: Meson is adding support for Rust and it's getting >> better, but Cargo is the canonical build system for Rust. cargo is >> released in lockstep with rustc, and we _have_ to use cargo when >> building with make because Meson won't be available in that case. >> * Crates: Patrick's series assumes the Git codebase is _the_ crate >> * cbindgen: Cbindgen outputs a single header file for each crate, >> with only 1 we'll have an unmanageably large auto generated header >> file. >> * Modularity: Using multiple crates makes Git more modular. Elijah >> told me that there was some desire to make Git more modular. >> * Cargo Dependencies: Patrick wrote his series with Meson first in >> mind which doesn't address how we'll be able to use crates from >> crates.io >> * CI: >> * Sparse coverage: I think there's only one target that tests his changes. >> * With vs Without Rust: I don't see anywhere that he covers >> building with vs without Rust in CI >> * Build integration: Meson has to have every .rs file specified >> where as the default layout of a Rust project allows Cargo to just >> know where to look for .rs files > > Yeah, as I mentioned my patch series here really aims at getting an > minimum viable user of Rust into the Git codebase so that we can focus > the discussion more on the roadmap towards Rust rather than the actual > Rust infrastructure. The whole infra is very simplistic because of that, > but that is intentional for now. > > Once we have agreed on the roadmap I very much expect that we will > iterate on it to allow for more complex use cases. My next step would > have been to pick patches from your series that make all of this work > on Windows. But of course I don't have to be the (only) one to iterate > on the initial simple infrasturcture, this should ideally be an effort > by the whole community. > > And yes, many of the points you mention above are things we'll have to > address over time to make Rust a viable alternative to implement > anything more complex than the trivial "varint.c" thing. I think that > iteration is key here: let's start simple and then gradually build out > the infrastructure.
I think adding external crates especially will need discussion given the licencing and "offline" issues (which are solvable but they should be examined).
> > Patrick