bors [Tue, 14 Feb 2017 19:46:26 +0000 (19:46 +0000)]
Auto merge of #3700 - matklad:faster-test, r=alexcrichton
Don't use real serde in tests
This test used to take 1.5 minutes on my machine (without significant CPU usage however), now it finishes in a couple of seconds. I don't fully understand what is tested here, but I suppose we don't really need serde.
bors [Mon, 13 Feb 2017 23:23:39 +0000 (23:23 +0000)]
Auto merge of #3689 - ms705:master, r=alexcrichton
More intuitive CARGO_INCREMENTAL semantics
Currently, the mere presence of a `CARGO_INCREMENTAL` variable in the environment causes incremental compilation to be enabled. This has the very counterintuitive effect that `CARGO_INCREMENTAL=0` and even `CARGO_INCREMENTAL=` mean incremental compilation is *on*.
This PR brings the semantics in line with how they are defined in the tests (cf. [tests/build.rs:45](https://github.com/rust-lang/cargo/blob/master/tests/build.rs#L45)), and in [public-facing documentation](https://internals.rust-lang.org/t/incremental-compilation-beta/4721).
See also [rust#39773](https://github.com/rust-lang/rust/issues/39773) for an example of this causing confusion in the wild.
bors [Mon, 13 Feb 2017 21:05:47 +0000 (21:05 +0000)]
Auto merge of #3684 - casey:search-copy-pastafication, r=alexcrichton
Increase copypastafication of `cargo search`
Formats the search results printed by `cargo search` so that they can be
copied directly into a `Cargo.toml` file.
I used `^`, since I like being explicit, although that seems not to be the convention, so I'd be happy to remote it.
I also added a `#` in front of the description, so that that can be copy pastaed as well. I'm not super attached to this idea, but I think it's interesting, since it would serve to document what the various dependencies of a crate are for new contributors.
For example:
```
$ cargo search clap
clap = "^2.20.3" # A simple to use, efficient, and full featured Command Line ArgumentParser
please-clap = "^0.1.0" # Pattern-match against Clap subcommands and arguments.
clapcomp = "^0.1.5" # clap completion generator as command
clap-test = "^0.1.1" # functions and macros to assist in testing clap
structopt = "^0.0.2" # Parse command line argument by defining a struct.
capgun = "^0.1.1" # fire when ready file watcher
structopt-derive = "^0.0.2" # Parse command line argument by defining a struct, derive crate.
cargo-outdated = "^0.3.0" # Cargo subcommand for displaying when dependencies are out of date
wesers = "^0.4.1" # a simple HTTP/HTTPS server in Rust
cargo-arch = "^0.1.0" # Rust Arch Linux package packer
... and 6 crates more (use --limit N to see more)
```
Previously, the mere presence of a CARGO_INCREMENTAL variable in the
environment caused incremental compilation to happen. This has the very
unintuitive effect that `CARGO_INCREMENTAL=0` and even
`CARGO_INCREMENTAL=` mean incremental compilation is *on*.
This change brings the semantics in line with how they are defined in
the tests (cf. tests/build.rs:45), and in public-facing documentation
(https://internals.rust-lang.org/t/incremental-compilation-beta/4721).
bors [Wed, 8 Feb 2017 01:03:17 +0000 (01:03 +0000)]
Auto merge of #3583 - alexcrichton:fix-tags, r=brson
Handle `rev` being a `tag`
Previously if a rev was specified as a tag then we'd trip an assertion because
resetting to that tag would reset to the tag that the commit pointed to, which
would then cause the head id of the repo to be different than what we thought it
was.
Instead, we handle the case where a `rev` specification is a tag explicitly by
using the tag's target id as the revision that we're going to check out, not the
id of the tag itself.
bors [Tue, 7 Feb 2017 22:02:51 +0000 (22:02 +0000)]
Auto merge of #3651 - pkgw:pr-issue-3366, r=alexcrichton
Attempt to solve #3366, regarding spurious shared library search paths.
This drops `native_dirs` entries that are not within the target output when modifying the (DY)LD_LIBRARY_PATH environment variable before running programs.
Peter Williams [Tue, 7 Feb 2017 20:55:36 +0000 (15:55 -0500)]
Attempt to fix the run_with_library_paths test for Windows.
I was just pasting the build directories into Rust string literals, so Windows
paths with backslashes were being interpreted as having unknown string
escapes. Raw string guards should fix this for all but the most pathological
of build directories.
bors [Tue, 7 Feb 2017 20:08:02 +0000 (20:08 +0000)]
Auto merge of #3664 - pwoolcoc:issue-3391, r=alexcrichton
Assume that a `build.rs` file is a build script
If cargo sees a `build.rs` file in the same directory as the current
`Cargo.toml`, it will assume that the `build.rs` file is a build script,
unless there is `build = false` in the `Cargo.toml` file.
Paul Woolcock [Tue, 7 Feb 2017 17:41:36 +0000 (12:41 -0500)]
Assume that a `build.rs` file is a build script
If cargo sees a `build.rs` file in the same directory as the current
`Cargo.toml`, it will assume that the `build.rs` file is a build script,
_unless there is_ `build = false` _in the _ `Cargo.toml` _file_.
Nathanael Jones [Tue, 7 Feb 2017 09:34:04 +0000 (02:34 -0700)]
Adjust test overrides_and_links.
While order between rust-c-link-lib and rustc-flags was always undefined
(for TOML configuration), order of link paths/libs within a single
rustc-flags value was maintained. Now we sort them all.
bors [Sun, 5 Feb 2017 22:29:03 +0000 (22:29 +0000)]
Auto merge of #3632 - Susurrus:master, r=alexcrichton
Document build badge for Gitlab CI
This doesn't make sense to merge until rust-lang/crates.io#539 is merged, but I figured I'd get it all spooled up since that PR is already ready for merging.
Peter Williams [Sun, 5 Feb 2017 21:15:24 +0000 (16:15 -0500)]
Attempt to solve #3366, regarding spurious shared library search paths.
This drops `native_dirs` entries that are not within the target directory when
modifying the (DY)LD_LIBRARY_PATH environment variable before running
programs.
bors [Sat, 4 Feb 2017 19:28:44 +0000 (19:28 +0000)]
Auto merge of #3648 - cuviper:powerpc64-gcc4, r=alexcrichton
Update OPENSSL_CC_powerpc64-unknown-linux-gnu
With the new `rust-slave-linux-cross:2017-02-02`, powerpc64 no longer
uses gcc-5. I updated the `Dockerfile` at the time to reflect this, but
missed `OPENSSL_CC_powerpc64-unknown-linux-gnu` in `Makefile.in`.
Josh Stone [Sat, 4 Feb 2017 01:59:30 +0000 (17:59 -0800)]
Update OPENSSL_CC_powerpc64-unknown-linux-gnu
With the new `rust-slave-linux-cross:2017-02-02`, powerpc64 no longer
uses gcc-5. I updated the `Dockerfile` at the time to reflect this, but
missed `OPENSSL_CC_powerpc64-unknown-linux-gnu` in `Makefile.in`.
bors [Fri, 3 Feb 2017 04:16:05 +0000 (04:16 +0000)]
Auto merge of #3634 - steveklabnik:bump-semver, r=alexcrichton
bump semver version
Thanks to @raphlinus , semver-parser no longer depends on regex. The code is (probably, I haven't technically tested it but it's hard to imagine it's not) faster, smaller, and has zero dependencies, as well as better errors.
This new version of semver only updates the dependencies involved, no interface changes, so it should be a drop-in replacement.
bors [Fri, 3 Feb 2017 00:59:41 +0000 (00:59 +0000)]
Auto merge of #3628 - zackmdavis:the_maelstrom_of_my_purity_born_of_pain, r=alexcrichton
make build tests not depend on minutiae of rustc output
This little patch arises from the maelstrom of my purity born of pain.
It's the pain of seeing rust-lang/rust#38103 in its perfect crystalline beauty waste away on page four of https://github.com/rust-lang/rust/pulls, waiting, ready, itching to land, dying with anticipation to bring the light of clearer lint group error messages to Rust users of all creeds and nations, only for its promise to be cruelly blocked by the fateful, hateful hand of circular dependency. For it is written in src/tools/cargotest/main.rs that the Cargo tests must pass before the PR can receive Appveyor's blessing, but the Cargo tests could not pass (because they depend on fine details of the output that the PR is meant to change), and the Cargo tests could not be changed (because updating the test expectation to match the proposed new compiler output, would fail with the current compiler).
The Gordian knot is cut in the bowels of cargotest's very notion of comparison (of JSON objects) itself, by means of introducing a magic string literal `"{...}"`, which can server as a wildcard for any JSON sub-object.
And so it will be for the children, and the children's children, and unto the 1.17.0 and 1.18.0 releases, that Cargo's build test expectations will faithfully expect the exact JSON output by Cargo itself, but the string literal `"{...}"` shall be a token upon the JSON output by rustc, and when I see `"{...}"`, I will pass over you, and the failure shall not be upon you.
Zack M. Davis [Wed, 1 Feb 2017 04:51:24 +0000 (20:51 -0800)]
make build tests not depend on minutiæ of rustc output
This little patch arises from the maelstrom of my purity born of pain.
It's the pain of seeing rust-lang/rust#38103 in its perfect
crystalline beauty waste away on page four of
https://github.com/rust-lang/rust/pulls, waiting, ready, itching to
land, dying with anticipation to bring the light of clearer lint group
error messages to Rust users of all creeds and nations, only for its
promise to be cruelly blocked by the fateful, hateful hand of circular
dependency. For it is written in src/tools/cargotest/main.rs that the
Cargo tests must pass before the PR can receive Appveyor's blessing,
but the Cargo tests could not pass (because they depend on fine
details of the output that the PR is meant to change), and the Cargo
tests could not be changed (because updating the test expectation to
match the proposed new compiler output, would fail with the current
compiler).
The Gordian knot is cut in the bowels of cargotest's very notion of
comparison (of JSON objects) itself, by means of introducing a magic
string literal `"{...}"`, which can server as a wildcard for any JSON
sub-object.
And so it will be for the children, and the children's children, and
unto the 1.17.0 and 1.18.0 releases, that Cargo's build test
expectations will faithfully expect the exact JSON output by Cargo
itself, but the string literal `"{...}"` shall be a token upon the
JSON output by rustc, and when I see `"{...}"`, I will pass over you,
and the failure shall not be upon you.
bors [Thu, 2 Feb 2017 02:15:05 +0000 (02:15 +0000)]
Auto merge of #3609 - jmatraszek:build_proper_binary, r=alexcrichton
Fix building multiple binaries that do not have path spacified in Cargo.toml
When multiple binaries are specified in Cargo.toml, the binaries that do not have `path` specified are build from `src/main.rs`. Discovered here: https://github.com/rust-lang-nursery/thanks/pull/40#issuecomment-275493045.
This was caused by setting for a binary a main layout here https://github.com/rust-lang/cargo/blob/master/src/cargo/util/toml.rs#L478, which caused `normalize` to not fallback to default binary path here https://github.com/rust-lang/cargo/blob/master/src/cargo/util/toml.rs#L1149 (as `bin.path` was always `Some("/path/to/main.rs")`.
Added a test and fixed this by not using `layout.main()`, so right now for bins without `path` specified we fallback to default path inferred from bin's name (e.g. `src/bin/foo.rs`), test if the file exists and only if it doesn't -- fallback to `src/main.rs`.
I do not have any knowledge about Cargo's design, so I am not sure if this is the proper place to test for file existence.
If `[members]` key present, it compliantly defines the set of members. Otherwise, members are all (transitive) path dependencies.
The problem with this approach is that it violates convention over configuration principle: almost always you want a path dependency to be a member, even if there are some explicit members. Listing **all** path deps is just to much work.
# Original implementation
So, the actual algorithm **unconditionally** included path dependencies as memebers.
This is also problematic, because certain workspace configurations become impossible. In particular, you can't have a path dependency which is not a member of the workspace. This issue was reported in #3192.
# Current implementation
Current implementation (was merged couple of days ago) includes path dependency into the workspace only if is inside the workspace directory. This solves the problem in #3192 perfectly. However, some configuration are still impossible: you can't have a non-member path dependency inside a workspace directory. But the thinking is that if you don't want this path-dep to be a member, just don't put it inside the workspace directory.
There is another problem with current imlementation. Suppose you have an explicit member which lives alongside the workspace. Suppose this member has a path-dep which lives inside the member's folder. Under current implementation, this path-dep won't be a member of the workspace. It seems logical that it should be though (but we haven't received any actual bug reports yet)!
# Implementation in this PR
So, with this PR, the logic is as follows: members are explicit members + all path dependencies which reside under any of the explicit members.
bors [Wed, 1 Feb 2017 22:22:19 +0000 (22:22 +0000)]
Auto merge of #3004 - ehiggs:master, r=alexcrichton
Resubmission of templating PR (#1747)
This is a manual rebase of the older #1747 PR which was basically unrebasable due to the time it's been dormant.. This implements templating for Cargo and is basically the work of Greg Chapple (@gchp).
I'd love for this feature to move forward since it's really tedious to create all the directories (e.g. `src/bin`) and copy paste docopt examples which I then edit. Then implement the `main` program to delegate to the subcommands in `src/bin`, etc.
projects / cargo.git / log