Allow cargo:rustc-env in build scripts
This is an attempt to address issue #2875. Basically, I'm trying to allow build scripts to produce`cargo:rustc-env=FOO=foo` lines in their output. These are then translated to `env!()`-friendly env. vars that rustc is run with.
When `target.$triple.runner` is specified, it will be used for any execution commands by cargo including `cargo run`, `cargo test` and `cargo bench`. The original file is passed to the runner executable as a first argument.
This allows to run tests when cross-comping Rust projects.
This is not a complete solution, and might be extended in future for better ergonomics to support passing extra arguments to the runner itself or overriding runner from command line, but it should already unlock major existing usecases.
Fixes#1411Resolves#3626
fix `cargo test` of dylib projects for end user runs too
Fixes running `cargo test` and `cargo test --target <target>` for dylib projects.
Moves the logic just landed in https://github.com/rust-lang/cargo/pull/3996 into cargo itself, so cargo sets the dylib path for anyone running `cargo test` or `cargo run`. Current master sets the dylib path only for `cargo test` on cargo itself.
This PR pins to rustup 1.2.0 for the purposes of testing. If https://github.com/rust-lang-nursery/rustup.rs/pull/1093 ends up working out, then this PR would only be important for non-rustup users and people doing cross testing, `cargo test --target <target>`.
Arguably ed273851f8/src/cargo/ops/cargo_rustc/context.rs (L249-L253) should point to lib/rustlib/\<host triple\>/lib instead of sysroot/lib, because I think if the libs are different, you will never be able to compile a working plugin anyway, and for the host=target case you get the lib/rustlib/\<host triple\>/lib anyhow. Is there ever a case where the lib/rustlib/\<host triple\>/lib and sysroot/lib versions of the libs would be expected to differ?
This is not a huge deal for me one way or the other - it doesn't impact my workflow at all. I nearly dropped it when I saw @alexcrichton had made it all work in 3996, but I think it's worth doing because it removes a surprise. It certainly would have saved me a couple of days of confusion. Either way, thanks for looking it over.
Make dynamic library search path handling for build scripts mirror the
behaviour for cargo run etc. -L paths are taken and stripped of the
native= and similar prefixes and added to the dynamic library search
path if they are inside the target dir.
Resolves https://github.com/rust-lang/cargo/issues/3957
Don't use `-C metadata` cdylibs like we do with dylibs
Dylibs don't get any metadata/extra filename info applied to them as "final
targets" because it can mess with system-specific information (e.g. on OSX) so
this just applies the same logic to cdylibs which need similar treatment on more
platforms (like Windows).
Closes#3934
Dylibs don't get any metadata/extra filename info applied to them as "final
targets" because it can mess with system-specific information (e.g. on OSX) so
this just applies the same logic to cdylibs which need similar treatment on more
platforms (like Windows).
Closes#3934
Relax overly strict asserts in dependency queue
Don't actually need to assert that these are unique, it works both ways and we
can have flavorful dependency graphs which otherwise trigger the assertions.
Closes#3902
Support vendor dirs with "empty" directories
Looks like when vendor directories are checked into a VCS there's been instances
where deleting a folder in the VCS doesn't fully delete the folder from the
filesystem. This can lead to [spurious errors][moz] that are difficult to debug.
To help handle this tweak directory sources to ignore empty directories or
directories with only dotfiles by default.
[moz]: https://bugzilla.mozilla.org/show_bug.cgi?id=1342292
Don't actually need to assert that these are unique, it works both ways and we
can have flavorful dependency graphs which otherwise trigger the assertions.
Closes#3902
Allow test named `test`
Looks like `srt/test.rs` and `src/bench.rs` used to be default
integraion test and benchmark, but they no longer are.
closes#3932
Implementation and CLI-support for `--all-$KIND` flags
This implements #3112.
This means all of the following commands are now possible and meaningful:
```
cargo build --all-bins
cargo build --all-tests
cargo test --all-tests
cargo test --all-bins
cargo check --all-bins --all-examples --all-tests --all-benches
```
The commits try to represent the incremental "propagation" of the new feature:
- core functionality (`cargo check --lib` passes)
- CLI suport (`cargo build` passes)
- additional tests (`cargo test` covers new functionality)
Note that `--all` is already reserved to mean "all packages of the workspace", so it can't be used to mean `--all-bins --all-examples --all-tests --all-benches`.
I intend to follow this up by some other PRs, so please do tell me where I could improve.
Add support for wrapping cargo's rustc invocations by setting RUSTC_WRAPPER
To use sccache for cargo builds we need a simple way to get sccache into the rustc commandline when cargo invokes rustc. Currently this is only possible by hard-linking or copying the `sccache` binary to be named `rustc` and then either setting `RUSTC` to its path or putting it first in `$PATH`, both of which are sort of clunky and require manual steps even if installing sccache via `cargo install`.
This patch adds support for a `RUSTC_WRAPPER` environment variable which, if set, will simply be inserted as the actual binary for all rustc process execution, with rustc and all other rustc arguments following.
I didn't add any tests for this, I couldn't figure out the right place to put them, and presumably we'd need to build a helper binary of some sort to use as the wrapper. If you've got suggestions for how to do that properly I'd be happy to write tests.
This works well in my local testing:
```
luser@eye7:/build/read-process-memory$ /build/cargo/target/release/cargo clean; time RUSTC_WRAPPER=/build/sccache2/target/release/sccache RUSTC=/home/luser/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/rustc /build/cargo/target/release/cargo build
Compiling getopts v0.2.14
Compiling log v0.3.6
Compiling libc v0.2.16
Compiling rand v0.3.14
Compiling pulldown-cmark v0.0.3
Compiling tempdir v0.3.5
Compiling skeptic v0.5.0
Compiling read-process-memory v0.1.2-pre (file:///build/read-process-memory)
Finished dev [unoptimized + debuginfo] target(s) in 7.31 secs
real 0m7.733s
user 0m0.060s
sys 0m0.036s
luser@eye7:/build/read-process-memory$ /build/cargo/target/release/cargo clean; time RUSTC_WRAPPER=/build/sccache2/target/release/sccache RUSTC=/home/luser/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/rustc /build/cargo/target/release/cargo build
Compiling getopts v0.2.14
Compiling libc v0.2.16
Compiling log v0.3.6
Compiling pulldown-cmark v0.0.3
Compiling rand v0.3.14
Compiling tempdir v0.3.5
Compiling skeptic v0.5.0
Compiling read-process-memory v0.1.2-pre (file:///build/read-process-memory)
Finished dev [unoptimized + debuginfo] target(s) in 0.97 secs
real 0m1.049s
user 0m0.060s
sys 0m0.036s
```
The use of beta rustc is just to pick up the fix for making `--emit=dep-info` faster (which should ship in 1.17). If this patch ships in cargo then in the future developers should simply be able to `cargo install sccache; export RUSTC_WRAPPER=sccache` and `cargo build` as normal, but benefit from local sccache caching.
Better error message when a package version is not found
This changes the error message when a package *is* found but there's no
matching version to be a little more helpful.
Old: "no matching package named `<dep name>`"
New: "no matching version `<version>` found for package `<dep name>`"
Fixes#2997
Adjust submodule updating failure reporting
This PR changes output of cargo when updating a dependency fails because of it's submodules cannot be loaded. In my original example this was caused by submodule pointing to a revision which was deleted by force pushing. Fixes#3922.
Before:
```
$ cargo check
Updating git repository `<foo-url>`
error: failed to load source for a dependency on `foo`
Caused by:
Unable to update <foo-url>?rev=hash
To learn more, run the command again with --verbose.
```
After:
```
$ cargo check
Updating git repository `<foo-url>`
error: failed to load source for a dependency on `foo`
Caused by:
Unable to update <foo-url>?rev=hash
Caused by:
Failed to update submodule `submodule`
To learn more, run the command again with --verbose.
```
`--verbose` showing an additional `[9/-3] object not found - no match for id (hash)` has not been changed.
@alexcrichton since we have this nice timezone difference there was no chance of mentoring so far but any comments/suggestions are highly welcome. I'll likely check back on this next week.
This changes the error message when a package *is* found but there's no
matching version to be a little more helpful.
Old: "no matching package named `...`"
New: "no matching version `...` found for package `...`"
Now instead of reporting single generic "submodule update failed" a
dependency specific submodule update failed error message will be
reported and shown without --verbose.
