Hi Josh, On Thu, 27 Mar 2025, Josh Steadmon wrote: > 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 If you need symbolic linkson Windows in CI, please set `MSYS=winsymlinks:nativestrict` like it is done here: https://github.com/git-for-windows/git/blob/4ca71ba5311a8f1bafbf002e97e076f15dcfc15b/t/t2040-checkout-symlink-attr.sh#L8-L10. It might fail, though, if it requires _Git_ to be able to create symbolic links because I have not yet managed to upstream the patches to implement that. We could fast-track support for `readlink()` without the other parts (https://github.com/git-for-windows/git/commit/86420a1b84d1), but last time I checked, Git's test suite did not pass under `MSYS=winsymlinks:nativestrict` for some reasons I was unable to analyze for lack of time. Ciao, Johannes
