Thread (6 messages) 6 messages, 2 authors, 2026-02-09

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

From: brian m. carlson <hidden>
Date: 2026-02-05 02:06:34

On 2026-02-05 at 01:45:53, Mike Hommey wrote:
On Thu, Feb 05, 2026 at 12:10:28AM +0000, brian m. carlson wrote:
quoted
On 2026-02-04 at 23:22:08, Mike Hommey wrote:
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help