Re: [PATCH v4 2/2] Makefile: support universal macOS builds via RUST_TARGETS

From: Shardul Natu <snatu@google.com>
Date: Jul 6, 2026, 18:36 UTC
Message-ID: <CABaQWZfS0utG6jfLcHTgHGYo_BTVJr=ZO4NuBDRPKRh+UF4Cvw@mail.gmail.com>

Show 5 quoted lines

> I was wondering why no other target declares an explicit dependency on
> RUST_LIB. As it turns out, all the other targets that link "$(LIBS)" all
> already depend on "$(GITLIBS)", which includes both "$(LIB_FILE)" and
> "$(RUST_LIB)". So shouldn't we also depend depend on "$(GITLIBS)" here
> instead of on either of the other two variables?

Ah, a much cleaner cleanup! Done

> s/rust/Rust/

Done

Show 14 quoted lines

> With this we now have both:
>
> - target/$ARCH/$BUILD_CONFIG/
>
> - target/$BUILD_CONFIG/
>
> Is there any reason why we have to have those two different layouts
> instead of swapping the order in the first item so that all artifacts
> are in "target/$BUILD_CONFIG/"? Essentially, what I'm proposing instead
> is:
>
> - "target/$BUILD_CONFIG/" for the final universal executable.
>
> - "target/$BUILD_CONFIG/$ARCH" for the per-arch artifacts.

When you invoke "cargo build --release --target x86_64-apple-darwin", Cargo automatically places the resulting artifacts under "target/x86_64-apple-darwin/release/".

If we tried to force Cargo to output under "target/release/$ARCH" by passing a custom "--target-dir", Cargo would still append its required "$ARCH/$BUILD_CONFIG/" structure inside that custom directory, resulting in nested paths like "target/release/$ARCH/$ARCH/release/libgitcore.a", or otherwise breaking Cargo's internal dependency caching and artifact sharing across builds.

And so, we have to have "target/$ARCH/$BUILD_CONFIG/" for per-arch artifacts.