Re: [RFC PATCH v1 2/4] libgit-sys: add symlink to git repo root and clean after build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux