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

1 messages from 2026-07-06 to 2026-07-06. Participants: Shardul Natu.
Thread: https://gitlist.dev/t/65933

## Shardul Natu, 2026-07-06 18:36

Subject: Re: [PATCH v4 2/2] Makefile: support universal macOS builds via RUST_TARGETS
Message-ID: <CABaQWZfS0utG6jfLcHTgHGYo_BTVJr=ZO4NuBDRPKRh+UF4Cvw@mail.gmail.com>

```
> 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


> 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.

```