On 2025.03.25 16:08, Junio C Hamano wrote: > Josh Steadmon <steadmon@xxxxxxxxxx> writes: > > > 2) keeping the top-level clean of any Rust code or configuration. > > > > If we're willing to have a Cargo.toml file in the repo root, ... > > If it is more like adding a new build configuration file whereever > we have Makefile (or meson.build), and is not like we are adding one > new file per one existing source file, then I see no reason why we > want to avoid adding a few files to the root-level. > > > ... we could > > create a "Cargo workspace", but I'm not sure yet if that avoids the same > > problem with accessing sources outside of the crates themselves. I'll be > > able to test it out later this week. > > Yeah, that would probably be a reasonable thing to try. Thanks. > > > > If the workspace approach doesn't work, the alternatives are: > > > > 1) avoid the issue for now; anyone who wants to experiment with > > libgit-rs can do so by building from source (but it will prevent them > > from creating their own packaged crates IIUC). > > > > 2) move libgit-sys and libgit-rs to separate repos and depend on the Git > > source via submodules. This is what I've seen done in other -sys crates > > such as zlib-sys (https://github.com/rust-lang/libz-sys). > > > > Of those alternatives, I prefer #1 for now. If we build enough momentum > > on libification and expanding the coverage of these crates, then we > > could think about switching to #2. > > Yeah, or putting it another way, #1 would help us gather enough Rust > minded folks who are familiar enough to come up with ideas and offer > better ways to manage this part of the system. > > Thanks. Unfortunately creating a workspace doesn't provide access to the top-level source. Symlinks seem to be the only recommended approach [1] for embedded crates, but since that breaks Windows CI let's just drop the series for now. [1] https://users.rust-lang.org/t/including-files-from-parent-directory-in-package/88969
