From: Shardul Natu Date: Mon, 06 Jul 2026 18:36:40 GMT Subject: Re: [PATCH v4 2/2] Makefile: support universal macOS builds via RUST_TARGETS Message-ID: > 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.