git/t/Makefile, branch jch

Merge branch 'da/cargo-serialize'

2025-09-08T21:54:34Z

Makefile tried to run multiple "cargo build" which would not work very well; serialize their execution to work it around. * da/cargo-serialize: Makefile: build libgit-rs and libgit-sys serially

Makefile: build libgit-rs and libgit-sys serially

2025-08-27T00:02:12Z

"make -JN" with INCLUDE_LIBGIT_RS enabled causes cargo lock warnings and can trigger ld errors during the build. The build errors are caused by two inner "make" invocations getting triggered concurrently: once inside of libgit-sys and another inside of libgit-rs. Make libgit-rs depend on libgit-sys so that "make" prevents them from running concurrently. Apply the same logic to the test invocations. Use cargo's "--manifest-path" option instead of "cd" in the recipes. Signed-off-by: David Aguilar Acked-by: Kyle Lippincott Signed-off-by: Junio C Hamano

t/unit-tests: finalize migration of reftable-related tests

2025-07-24T18:46:04Z

The old `lib-reftable.{c,h}` implemented helper functions for our homegrown unit-testing framework. As part of migrating reftable-related tests to the Clar framework, Clar-specific versions of these functions in `lib-reftable-clar.{c,h}` were introduced. Now that all test files using these helpers have been converted to Clar, we can safely remove the original `lib-reftable.{c,h}` and rename the Clar- specific versions back to `lib-reftable.{c,h}`. This restores a clean and consistent naming scheme for shared test utilities. Finally, update our build system to reflect the changes made and remove redundant code related to the reftable tests and our old homegrown unit-testing setup. `test-lib.{c,h}` remains unchanged in our build system as some files particularly `t/helper/test-example-tap.c` depends on it in order to run, and removing that would be beyond the scope of this patch. Signed-off-by: Seyi Kuforiji Signed-off-by: Junio C Hamano

Makefile: stop requiring Perl when running tests

2025-04-07T21:47:38Z

The Makefile for our tests has a couple of targets that depend on Perl. Adapt those targets to only run conditionally in case Perl is available on the system so that it becomes possible to run the test suite without Perl. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

libgit: add higher-level libgit crate

2025-01-29T23:06:50Z

The C functions exported by libgit-sys do not provide an idiomatic Rust interface. To make it easier to use these functions via Rust, add a higher-level "libgit" crate, that wraps the lower-level configset API with an interface that is more Rust-y. This combination of $X and $X-sys crates is a common pattern for FFI in Rust, as documented in "The Cargo Book" [1]. [1] https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages Co-authored-by: Josh Steadmon Signed-off-by: Josh Steadmon Signed-off-by: Calvin Wan Signed-off-by: Junio C Hamano

libgit-sys: introduce Rust wrapper for libgit.a

2025-01-28T22:45:47Z

Introduce libgit-sys, a Rust wrapper crate that allows Rust code to call functions in libgit.a. This initial patch defines build rules and an interface that exposes user agent string getter functions as a proof of concept. This library can be tested with `cargo test`. In later commits, a higher-level library containing a more Rust-friendly interface will be added at `contrib/libgit-rs`. Symbols in libgit can collide with symbols from other libraries such as libgit2. We avoid this by first exposing library symbols in public_symbol_export.[ch]. These symbols are prepended with "libgit_" to avoid collisions and set to visible using a visibility pragma. In build.rs, Rust builds contrib/libgit-rs/libgit-sys/libgitpub.a, which also contains libgit.a and other dependent libraries, with -fvisibility=hidden to hide all symbols within those libraries that haven't been exposed with a visibility pragma. Co-authored-by: Kyle Lippincott Co-authored-by: Calvin Wan Signed-off-by: Calvin Wan Signed-off-by: Kyle Lippincott Signed-off-by: Josh Steadmon Signed-off-by: Junio C Hamano

t/Makefile: make "check-meson" work with Dash

2024-12-27T16:28:11Z

The "check-meson" target uses process substitution to check whether extracted contents from "meson.build" match expected contents. Process substitution is unportable though and thus the target will fail when using for example Dash. Fix this by writing data into a temporary directory. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Makefile: detect missing Meson tests

2024-12-13T14:48:46Z

In the preceding commit, we have introduced consistency checks to Meson to detect any discrepancies with missing or extraneous tests in its build instructions. These checks only get executed in Meson though, so any users of our Makefiles wouldn't be alerted of the fact that they have to modify the Meson build instructions in case they add or remove any tests. Add a comparable test target to our Makefile to plug this gap. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Makefile: wire up the clar unit testing framework

2024-09-04T15:41:37Z

Wire up the clar unit testing framework by introducing a new "unit-tests" executable. In contrast to the existing framework, this will result in a single executable for all test suites. The ability to pick specific tests to execute is retained via functionality built into the clar itself. Note that we need to be a bit careful about how we need to invalidate our Makefile rules. While we obviously have to regenerate the clar suite when our test suites change, we also have to invalidate it in case any of the test suites gets removed. We do so by using our typical pattern of creating a `GIT-TEST-SUITES` file that gets updated whenever the set of test suites changes, so that we can easily depend on that file. Another specialty is that we generate a "clar-decls.h" file. The test functions are neither static, nor do they have external declarations. This is because they are getting parsed via "generate.py", which then creates the external generations that get populated into an array. These declarations are only seen by the main function though. The consequence is that we will get a bunch of "missing prototypes" errors from our compiler for each of these test functions. To fix those errors, we extract the `extern` declarations from "clar.suite" and put them into a standalone header that then gets included by each of our unit tests. This gets rid of compiler warnings for every function which has been extracted by "generate.py". More importantly though, it does _not_ get rid of warnings in case a function really isn't being used by anything. Thus, it would cause a compiler error if a function name was mistyped and thus not picked up by "generate.py". The test driver "unit-test.c" is an empty stub for now. It will get implemented in the next commit. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

t: do not pass GIT_TEST_OPTS to unit tests with prove

2024-09-04T15:41:36Z

When using the prove target, we append GIT_TEST_OPTS to the arguments that we execute each of the tests with. This doesn't only include the intended test scripts, but also ends up passing the arguments to our unit tests. This is unintentional though as they do not even know to interpret those arguments, and is inconsistent with how we execute unit tests without prove. This isn't much of an issue because our current set of unit tests mostly ignore their arguments anyway. With the introduction of clar-based unit tests this is about to become an issue though, as these do parse their command line argument to alter behaviour. Prepare for this by passing GIT_TEST_OPTS to "run-test.sh" via an environment variable. Like this, we can conditionally forward it to our test scripts, only. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano