Re: [RFC PATCH] Move rust gitcore crate to a different subdirectory

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Feb 5, 2026, 02:06 UTC
Message-ID: <aYP7KKD1tDsormI3@fruit.crustytoothpaste.net>
In-Reply-To: <5h7fs4smilvvuqyry4uef3rjgky5woodmapb3fy72src2hvlzv@o3bbh7zxqqvt>

On 2026-02-05 at 01:45:53, Mike Hommey wrote:

Show 23 quoted lines

> On Thu, Feb 05, 2026 at 12:10:28AM +0000, brian m. carlson wrote:
> > On 2026-02-04 at 23:22:08, Mike Hommey wrote:
> > > While `src/` is the default directory convention for Rust projects, it
> > > is too generic in the context of a multi-language project that is barely
> > > starting to (optionally) use Rust code.
> > > 
> > > Additionally, having `Cargo.toml` at the top-level of the repository
> > > implies that one can run `cargo build` directly, but this doesn't
> > > produce anything useful on its own.
> > > 
> > > Moving all Rust-specific files into a dedicated `rust/` subdirectory
> > > makes things clearer.
> > 
> > If we're going to do this, we should place the `src` directory under the
> > `rust` subdirectory to maintain the normal layout.  There are many tools
> > that depend on this repository layout and we want to make it as easy as
> > possible for people to use native, standard tooling to build things.
> 
> Not that I'm going to argue your preference, but I'm curious what tools
> you'd know that would not support a layout different than the typical
> one, because that means they're broken with some existing crates (e.g.
> those from https://github.com/servo/servo/) and should probably be
> fixed.

One of my goals is to see if we can get Git's Rust code to compile with mrustc since that might make it easier for NonStop, as well as some Linux OSes on obsolete architectures.

I can tell you from my experience that mrustc's cargo implementation is extremely limited and does only the bare minimum in terms of functionality. It already needs some help to work with static libraries, but I'd really like to minimize the work that needs to be done on it since it's not lovely code, and using a standard layout is going to help with minimizing the necessary changes. I will admit that I haven't tested using a non-standard layout, but I fully expect it will not work based on my experience of the codebase.

Certainly people may think this is folly, but it costs nothing for us to keep the standard layout and make the porting process a little easier.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA