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.