Message ID | cover.1736971328.git.steadmon@google.com (mailing list archive) |
---|---|
Headers | show |
Series | Introduce libgit-rs, a Rust wrapper around libgit.a | expand |
Josh Steadmon <steadmon@google.com> writes: > Apologies for the long delay on V6; I am finally back after several > months of $DAYJOB firefighting, holidays, and sick leave. I should have > time to devote to this series again, but given the lack of feedback on > V5 I am hopeful that this will be the final iteration of this series. Thanks and welcome back ;-) Given the lack of feedback on the previous round, I hope we will see enthused support on the topic. Otherwise it is hard to tell if the previous lack of feedback was merely lack of interest, or lack of anything lacking in the series. > There is known NEEDSWORK, but I feel that they can be addressed in > follow-up changes, rather than in this series. If you feel otherwise, > please let me know: > > * Investigate alternative methods of managing symbol visibility & > renaming. > > * Figure out symbol versioning OK. Let's see what people find out.
On 2025-01-15 at 20:05:39, Josh Steadmon wrote: > Apologies for the long delay on V6; I am finally back after several > months of $DAYJOB firefighting, holidays, and sick leave. I should have > time to devote to this series again, but given the lack of feedback on > V5 I am hopeful that this will be the final iteration of this series. > > This series provides two small Rust wrapper libraries around parts of > Git: "libgit-sys", which exposes a few functions from libgit.a, and > "libgit", which provides a more Rust-friendly interface to some of those > functions. In addition to included unit tests, at $DAYJOB we have tested > building JJ[1] with our library and used it to replace some of the > libgit2-rs uses. > > [1] https://github.com/martinvonz/jj > > There is known NEEDSWORK, but I feel that they can be addressed in > follow-up changes, rather than in this series. If you feel otherwise, > please let me know: > > * Investigate alternative methods of managing symbol visibility & > renaming. > > * Figure out symbol versioning It looks like we're building a general Rust lib crate and a static library here, so symbol versioning isn't an issue. I expect in the future we may want to provide a shared library, in which case we will indeed want to do that, but I agree that can wait until later. In any event, I overall think this series is a nice improvement, and I am very enthusiastic about it. (This is mostly for the benefit of Junio, since I think the authors of this series already know that.) Once it lands, I do plan to build on it somewhat.
"brian m. carlson" <sandals@crustytoothpaste.net> writes: > It looks like we're building a general Rust lib crate and a static > library here, so symbol versioning isn't an issue. I expect in the > future we may want to provide a shared library, in which case we will > indeed want to do that, but I agree that can wait until later. > > In any event, I overall think this series is a nice improvement, and I > am very enthusiastic about it. (This is mostly for the benefit of > Junio, since I think the authors of this series already know that.) > Once it lands, I do plan to build on it somewhat. ;-) Thanks, I heard you.