Single profile for build dependencies

[jdub]

I've just noticed that build dependencies are currently rebuilt for each profile (or at least debug and release, I haven't noticed what happens for the others).

That's fine for a little build helper like gcc, but painful for bindgen (mainly due to syntex_syntax build time).

Are there circumstances in which the build dependency build profile is relevant to the main project build? I could very well be missing something here.

If it's never relevant, then having to rebuild all your build dependencies for each profile is a (minor) pain.

Potential solutions:

Only build the build dependencies once…

• Optimise for performance: … with the release profile.
• Optimise for failure: … with the debug profile.
• Optimise for control: … with a new build profile, configured in the project's Cargo.toml like the others (and choose defaults from the above, I guess).

Thoughts?

[alexcrichton]

Yeah I've often wondered this in the past as well. I feel like choosing debug is the right default (most build scripts are not cpu bound) with the ability to tweak it (e.g. profile.build) would be the best way forward.

[jdub]

I discovered an inter-related problem. It could be regarded as a different bug. Let me know.

I'm pretty sure that build dependencies should disregard both the profile (as above) and the target.

An example failure follows. As you can see, cargo rustc is attempting to depend on std, which is not available for the custom target. I double-checked this behaviour with cargo build.

This kind of surprises me, and makes me wonder if I'm doing something wrong. Have people simply not been using cargo for cross-compiles with build dependencies? In this case, it's just x86 on x86_64, but how would an ARM build work on x86_64 with build dependencies built for ARM?

Oh, by the way, in this case libc is a build dependency of a dependency.

cargo rustc --verbose --target=i686-unknown-linux-gnu.json -- -C soft-float -C lto -C opt-level=1 -Z no-landing-pads
...
/home/jdub/.cargo/registry/src/github.com-0a35038f75765ae4/libc-0.1.8/rust/src/liblibc/lib.rs:1:1: 1:1 error: can't find crate for `std`
/home/jdub/.cargo/registry/src/github.com-0a35038f75765ae4/libc-0.1.8/rust/src/liblibc/lib.rs:1 // Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT
                                                                                                ^
error: aborting due to previous error
Could not compile `libc`.

Caused by:

  Process didn't exit successfully: `rustc /home/jdub/.cargo/registry/src/github.com-0a35038f75765ae4/libc-0.1.8/rust/src/liblibc/lib.rs --crate-name libc --crate-type lib -g --cfg feature="default" --cfg feature="cargo-build" -C metadata=ef5cbad4ef5c7a1e -C extra-filename=-ef5cbad4ef5c7a1e --out-dir /home/jdub/src/derp/derp/target/i686-unknown-linux-gnu/debug/deps --emit=dep-info,link --target i686-unknown-linux-gnu.json -C linker=util/linker.sh -L dependency=/home/jdub/src/derp/derp/target/i686-unknown-linux-gnu/debug/deps -L dependency=/home/jdub/src/derp/derp/target/i686-unknown-linux-gnu/debug/deps -Awarnings` (exit code: 101)

[alexcrichton]

I think this problem is orthogonal to build dependencies, but the problem you're seeing is that your compiler cannot target 32-bit windows because you're missing the standard library. Each Rust installation comes with a set of folders for the targets it has libraries for, and if these aren't present then there truly is no standard library to link against.

For any cross compilation scenario the first step is to ensure that you have those dependencies (e.g. std and everything under the facade). We plan on making this much easier to do in the future, so stay tuned!

[jdub]

That makes total sense for dependencies, but shouldn't build dependencies be built for the current machine (i.e. without --target)?

Aha! Now that I look more closely, I notice that immediate build dependencies are built without --target. In the following log, core is built with --target, but filetime and gcc are not. Perfect.

But in the previous log, libc was only being built for the benefit of...

🥚 👉 😵

Damn it. I didn't disable the non-build dependency. Sorry.

   Compiling core v0.0.0 (file:///home/jdub/src/derp/derp)
     Running `rustc vendor/libcore/src/lib.rs --crate-name core --crate-type lib -g -C metadata=7eddcbb0a532076f -C extra-filename=-7eddcbb0a532076f --out-dir /home/jdub/src/derp/derp/target/i686-unknown-linux-gnu/debug/deps --emit=dep-info,link --target i686-unknown-linux-gnu.json -C linker=util/linker.sh -L dependency=/home/jdub/src/derp/derp/target/i686-unknown-linux-gnu/debug/deps -L dependency=/home/jdub/src/derp/derp/target/i686-unknown-linux-gnu/debug/deps`
   Compiling filetime v0.1.4
     Running `rustc /home/jdub/.cargo/registry/src/github.com-0a35038f75765ae4/filetime-0.1.4/src/lib.rs --crate-name filetime --crate-type lib -g -C metadata=98fab2a8e902dde6 -C extra-filename=-98fab2a8e902dde6 --out-dir /home/jdub/src/derp/derp/target/debug/deps --emit=dep-info,link -L dependency=/home/jdub/src/derp/derp/target/debug/deps -L dependency=/home/jdub/src/derp/derp/target/debug/deps -Awarnings`
   Compiling gcc v0.3.8 (file:///home/jdub/src/derp/derp)
     Running `rustc /home/jdub/src/derp/gcc-rs/src/lib.rs --crate-name gcc --crate-type lib -g -C metadata=d4b5f7b7ec599315 -C extra-filename=-d4b5f7b7ec599315 --out-dir /home/jdub/src/derp/derp/target/debug/deps --emit=dep-info,link -L dependency=/home/jdub/src/derp/derp/target/debug/deps -L dependency=/home/jdub/src/derp/derp/target/debug/deps --extern filetime=/home/jdub/src/derp/derp/target/debug/deps/libfiletime-98fab2a8e902dde6.rlib`