On 2025.03.18 16:24, Josh Steadmon wrote:

Unlike `cargo build`, `cargo package` does not get access to the entire Git repo
containing a Rust crate. Instead, it prepares a directory starting from the
crate root (potentially excluding files, such as those not under version
control, or explicity excluded in the Cargo.toml file).

This means that the current method of building the libgit-sys crate does not
work with `cargo package`, as it tries to execute the Makefile from "../.."
relative to the crate root.

Fix this by adding a `git-src` symlink in the crate that points to the Git
repository root. `cargo package` will flatten this to a copy of the Git repo,
excluding non-version-controlled files, any explicitly-excluded files, and trees
that contain a Cargo.toml file (this prevents infinite recursion on the
symlink).

We can then execute the Makefile under the flattened git-src directory from our
build.rs script. However, this exposes a second problem; Cargo will check that
the build script does not add, delete, or modify any source files. This means
that after we copy our libgitpub.a dependency to the output directory, we must
run `make clean` to remove the object files we created during the build process.

Unfortunately, there is not a way to determine from the build.rs script whether
we're running `cargo build` vs. `cargo package`, so now any build of the
libgit-sys crate will result in cleaning the Git worktree.

A potential alternative is to make an additional temporary copy of the worktree
and run the Makefile there. This would avoid removing build artifacts in the
worktree at the cost of copying MBs worth of source files to a temporary
directory. Perhaps hardlinking instead of making a full copy would help here,
but that might be less portable.

I'm currently working on an alternate solution where we build the object
files in Cargo's working directory, rather than in the source tree. This
will (mostly) avoid the need to clean after the build. I hope to send a
v2 with this change in the next few days.