Without actually giving anything to link (for example, because the code
contains `#[link(name="foo")]`. In this case, we aren't actually passing
`-L` through when running doctests, even though they're passed when
compiling the main crate.
Sean Griffin [Sat, 19 Dec 2015 19:44:34 +0000 (12:44 -0700)]
Remove needless dylib check, add test
In this case the dylib check isn't actually doing anything useful, as
we're just appending search paths. Also adds a test for 8c65284b44337c6cfc003cedc8996e241ac678bd
bors [Fri, 18 Dec 2015 18:43:14 +0000 (18:43 +0000)]
Auto merge of #2223 - alexcrichton:better-dev-experience, r=brson
Each test wants to be sure to reset HOME and remove CARGO_HOME from the
environment, but this was done inconsistently throughout the test suite. This
commit consolidates process creation so there's only one point for creating a
process ready to execute the Cargo that's being tested.
bors [Thu, 17 Dec 2015 23:08:10 +0000 (23:08 +0000)]
Auto merge of #2219 - matklad:encodable-audit, r=alexcrichton
@alexcrichton another preparation PR for #2196
I've removed obscure `metadata` field from `Target`. It is a breaking change (for read-manifest), but the field seemed cryptic, useless and untested :)
`Target` has a bunch of boolean fields:
```
tested: bool,
benched: bool,
doc: bool,
doctest: bool,
harness: bool, // whether to use the test harness (--test)
for_host: bool,
```
I guess they should not be included in serialized representation?
Without actually giving anything to link (for example, because the code
contains `#[link(name="foo")]`. In this case, we aren't actually passing
`-L` through when running doctests, even though they're passed when
compiling the main crate.
Alex Crichton [Thu, 17 Dec 2015 17:53:14 +0000 (09:53 -0800)]
Consolidate creating processes in tests
Each test wants to be sure to reset HOME and remove CARGO_HOME from the
environment, but this was done inconsistently throughout the test suite. This
commit consolidates process creation so there's only one point for creating a
process ready to execute the Cargo that's being tested.
bors [Tue, 8 Dec 2015 15:08:13 +0000 (15:08 +0000)]
Auto merge of #2201 - matklad:serialized-dep, r=alexcrichton
This hides `SerializedDependency` from general public, as requested [here](https://github.com/rust-lang/cargo/pull/1434#issuecomment-97886950). It also hides `SerializedManifest` which was (wrongly?) exposed.
This is required for #2196. I want to move in small steps this time, hence the separate PR.
Technically this break backwards compatibility, because `SerializedDependency` and `SerializedManifest` were public (`SerializedPackage` was private however). Are such changes allowed in cargo?
bors [Fri, 4 Dec 2015 00:06:21 +0000 (00:06 +0000)]
Auto merge of #2134 - alexcrichton:build-script-input, r=brson
Currently Cargo is quite conservative in how it determines whether a build
script should be run. The heuristic used is "did any file in the project
directory change", but this is almost always guaranteed to be too coarse
grained in situations like:
* If the build script takes a long time to run it's advantageous to run it as
few times as possible. Being able to inform Cargo about precisely when a build
script should be run should provide more robust support here.
* Build scripts may not always have all of their dependencies in-tree or in the
crate root. Sometimes a dependency could be elsewhere in a repository and
scripts need a method of informing Cargo about this (as currently these
compiles don't happen then they should).
This commit adds this support in build scripts via a new `rerun-if-changed`
directive which can be printed to standard output (using the standard Cargo
metadata format). The value for this key is a path relative to the crate root,
and Cargo will only look at these paths when determining whether to rerun the
build script. Any other file changes will not trigger the build script to be
rerun.
Currently the printed paths may either be a file or a directory, and a directory
is deeply traversed. The heuristic for trigger a rerun is detecting whether any
input file has been modified since the build script was last run (determined by
looking at the modification time of the output file of the build script). This
current implementation means that if you depend on a directory and then delete a
file within it the build script won't be rerun, but this is already the case and
can perhaps be patched up later.
Future extensions could possibly include the usage of glob patterns in build
script paths like the `include` and `exclude` features of `Cargo.toml`, but
these should be backwards compatible to add in the future.
bors [Wed, 2 Dec 2015 00:50:33 +0000 (00:50 +0000)]
Auto merge of #2186 - alexcrichton:transaction, r=brson
Right now a `Bomb` struct is used to attempt to ensure that broken tarballs
don't escape, but this unfortunately doesn't work for when Cargo is terminated
via other means such as ctrl-c or abnormal termination. Instead the tarball is
constructed in a temporary location and then only moved to the final location
once all checks pass.
bors [Mon, 30 Nov 2015 20:16:08 +0000 (20:16 +0000)]
Auto merge of #2184 - brandonson:master, r=alexcrichton
When the crate to install is unspecified, we should really inform users about
where they can install from (other than crates.io). This makes the message mention --path
and --git so that people know they exist.
Alex Crichton [Mon, 30 Nov 2015 19:29:15 +0000 (11:29 -0800)]
Package/test tarballs in a temporary location
Right now a `Bomb` struct is used to attempt to ensure that broken tarballs
don't escape, but this unfortunately doesn't work for when Cargo is terminated
via other means such as ctrl-c or abnormal termination. Instead the tarball is
constructed in a temporary location and then only moved to the final location
once all checks pass.
When the crate to install is unspecified, we should really inform users about
where they can install from (other than crates.io). This makes the message mention --path
and --git so that people know they exist.
bors [Tue, 24 Nov 2015 00:10:33 +0000 (00:10 +0000)]
Auto merge of #2168 - durka:patch-3, r=alexcrichton
In c9f1b9bf1e535a651f624897bd53a3f81af7501f the format of this example was changed from a `[dependencies.awesome]` section to the newly-recommended inline table syntax, but one of the attributes was left out.
I had to use some slightly weird formatting to keep the comment in place, is that OK?
iirelu [Mon, 23 Nov 2015 16:56:10 +0000 (16:56 +0000)]
Make usage of vec! macro consistent
Previously it was a mix of vec!() and vec![], as both work thanks to the
implementation of macros in Rust (even vec!{} would work), this makes
them all use the generally-accepted vec![] standard, which imitates the
syntax used for slices and is considered to make things clearer.
bors [Mon, 23 Nov 2015 05:31:49 +0000 (05:31 +0000)]
Auto merge of #2166 - alexcrichton:clean-up-update, r=huonw
I've noticed some slightly odd output from `cargo update` in the past and I
believe this cleanup should address what's going on under the hood. There were a
few minor issues with the previous implementation.
* When adding the previous graph to the list of changes, packages with multiple
versions would override one another instead of all get added to one list.
* The `Ord` implementation for `SourceId` was actually incorrect in that it
disagreed with the `Eq` implementation. This could end up causing subtle bugs
here and there. dependening on what operators were used.
This tweak fixes both points and I believe should touch up the odd output I've
been seeing from `cargo update`.
Alex Crichton [Mon, 23 Nov 2015 05:18:59 +0000 (21:18 -0800)]
Clean up the `cargo update` implementation a bit
I've noticed some slightly odd output from `cargo update` in the past and I
believe this cleanup should address what's going on under the hood. There were a
few minor issues with the previous implementation.
* When adding the previous graph to the list of changes, packages with multiple
versions would override one another instead of all get added to one list.
* The `Ord` implementation for `SourceId` was actually incorrect in that it
disagreed with the `Eq` implementation. This could end up causing subtle bugs
here and there. dependening on what operators were used.
This tweak fixes both points and I believe should touch up the odd output I've
been seeing from `cargo update`.
bors [Fri, 20 Nov 2015 22:25:31 +0000 (22:25 +0000)]
Auto merge of #2160 - alexcrichton:bail-macro, r=huonw
This pattern showed up quite a few locations throughout the codebase but it
ended up meaning that there were some massive levels of indentation when you
actually get to the formatting string. This commit adds a new `bail!` macro
which shortens this idiom to help get the indentation under control throughout
the codebase.
Alex Crichton [Fri, 20 Nov 2015 18:46:43 +0000 (10:46 -0800)]
Add a macro for `return Err(human(format!(...)))`
This pattern showed up quite a few locations throughout the codebase but it
ended up meaning that there were some massive levels of indentation when you
actually get to the formatting string. This commit adds a new `bail!` macro
which shortens this idiom to help get the indentation under control throughout
the codebase.
bors [Wed, 18 Nov 2015 15:56:39 +0000 (15:56 +0000)]
Auto merge of #2151 - IvanUkhov:typography, r=steveklabnik
Hi,
Here are a number of commits making cosmetic adjustments to the documentation. The major change concerns the usage of quotation marks. If needed, some of the commits can be removed, and the rest can be squashed into one. Thanks.
bors [Sun, 15 Nov 2015 21:02:59 +0000 (21:02 +0000)]
Auto merge of #2131 - alexcrichton:cargo-clean, r=brson
* Clean out both host/target platforms if any are available.
* Clean out build script output.
* Add a --release flag to also be able to clean out release folder
* Be sure to clean out benchmarks, tests, etc.
* Cleaning out registry packages no longer panics
Alex Crichton [Tue, 10 Nov 2015 17:41:06 +0000 (09:41 -0800)]
Fix a number of bugs with cargo clean
* Clean out both host/target platforms if any are available.
* Clean out build script output.
* Add a --release flag to also be able to clean out release folder
* Be sure to clean out benchmarks, tests, etc.
* Cleaning out registry packages no longer panics
Alex Crichton [Wed, 11 Nov 2015 00:39:15 +0000 (16:39 -0800)]
Allow build scripts to specify dependencies
Currently Cargo is quite conservative in how it determines whether a build
script should be run. The heuristic used is "did any file in the project
directory change", but this is almost always guaranteed to be too coarse
grained in situations like:
* If the build script takes a long time to run it's advantageous to run it as
few times as possible. Being able to inform Cargo about precisely when a build
script should be run should provide more robust support here.
* Build scripts may not always have all of their dependencies in-tree or in the
crate root. Sometimes a dependency could be elsewhere in a repository and
scripts need a method of informing Cargo about this (as currently these
compiles don't happen then they should).
This commit adds this support in build scripts via a new `rerun-if-changed`
directive which can be printed to standard output (using the standard Cargo
metadata format). The value for this key is a path relative to the crate root,
and Cargo will only look at these paths when determining whether to rerun the
build script. Any other file changes will not trigger the build script to be
rerun.
Future extensions could possibly include the usage of glob patterns in build
script paths like the `include` and `exclude` features of `Cargo.toml`, but
these should be backwards compatible to add in the future.
Alex Crichton [Wed, 11 Nov 2015 02:08:06 +0000 (18:08 -0800)]
Refactor testing the registry
Use a builder to publish packages instead of a one-off function with many
variants, should provide a much finer grained level of configurability for
future test cases against the registry.
bors [Tue, 10 Nov 2015 07:16:25 +0000 (07:16 +0000)]
Auto merge of #2126 - johshoff:default_dependency_header, r=alexcrichton
Almost any project beyond "hello world" will have some dependencies.
Including the `[dependencies]` header by default makes this slightly
simpler.
For new users of the language, this can potentially save some
frustration since crates.io currently does not mention the header, just
the line that goes beneath it.
For all users, this makes adding the first dependency to a project less
of a special case than to subsequent dependencies.