Alex Crichton [Fri, 19 Feb 2016 21:49:14 +0000 (13:49 -0800)]
Merge the get/download methods on the Source trait
Nothing currently implements the ability to more efficiently download a set of
packages at any one point in time, and the download/get distinction isn't really
used at all. We can always refactor later, but currently there's no benefit, nor
can it really be seen what the possible benefit is, so let's just merge these
two methods into one and have them operate on one id at a time.
Alex Crichton [Fri, 19 Feb 2016 21:16:14 +0000 (13:16 -0800)]
Move the `get_package` step later when calculating deps
Future calls to `get_package` may end up actually downloading a package, so we
want to defer this as late as possible to ensure that we don't download
anything.
Alex Crichton [Fri, 19 Feb 2016 19:15:39 +0000 (11:15 -0800)]
Refactor build script output state initialization
Like with the previous refactor, remove the need to list all packages in a
package set as we only need to lazily do this for the actual packages being
compiled. Whenever a build script is requested to be executed is when we
actually go and try to see if an override was in play.
Alex Crichton [Fri, 19 Feb 2016 19:02:17 +0000 (11:02 -0800)]
Refactor links validation to not use PackageSet
Eventually we may not have the entire set of packages resident in memory, so
refactor the implementation to validate the `links` attribute in a demand driven
way rather than all at once up front.
Alex Crichton [Fri, 19 Feb 2016 18:53:57 +0000 (10:53 -0800)]
Fuse SourceMap and PackageSet
This commit moves the SourceMap structure into the PackageSet structure, and
simultaneously massively cuts down on the API surface area of PackageSet. It's
intended that eventually a PackageSet will be a lazily loaded set of packages so
we don't have to download everything all at once, and this is the commit in
preparation of that.
bors [Thu, 18 Feb 2016 17:12:57 +0000 (17:12 +0000)]
Auto merge of #2393 - WiSaGaN:bugfix/tests-mod-naming, r=alexcrichton
In the default `lib.rs` provided by `cargo-new`, the "test" module is named "test" while Rust convention is using "tests" as the name of the module: https://doc.rust-lang.org/book/testing.html#the-tests-module
The plural form also conforms with the style used in special directories at project root such as "examples" and "tests".
This pull request conforms to the existing style.
bors [Tue, 16 Feb 2016 18:51:49 +0000 (18:51 +0000)]
Auto merge of #2328 - alexcrichton:target-specific-deps, r=brson
This commit is an implementation of [RFC 1361][rfc] which is an extension of
Cargo's `target` section in `Cargo.toml` to allow the use of `#[cfg]`-like
expressions for target-specific dependencies. Now that the compiler has been
extended with `--print cfg` each invocation of Cargo will scrape this output and
learn about the relevant `#[cfg]` directives in play for the target being
compiled. Cargo will then use these directives to decide whether a dependency
should be activated or not.
This should allow definition of dependencies along the lines of:
Alex Crichton [Tue, 26 Jan 2016 00:54:10 +0000 (16:54 -0800)]
Implement cfg-based target-specific dependencies
This commit is an implementation of [RFC 1361][rfc] which is an extension of
Cargo's `target` section in `Cargo.toml` to allow the use of `#[cfg]`-like
expressions for target-specific dependencies. Now that the compiler has been
extended with `--print cfg` each invocation of Cargo will scrape this output and
learn about the relevant `#[cfg]` directives in play for the target being
compiled. Cargo will then use these directives to decide whether a dependency
should be activated or not.
This should allow definition of dependencies along the lines of:
bors [Thu, 11 Feb 2016 19:51:06 +0000 (19:51 +0000)]
Auto merge of #2370 - alexcrichton:windows-jobs, r=brson
Currently it's somewhat surprising if you're using cargo and it's then ctrl-c'd.
The child processes that Cargo spawned are likely to still be running around in
the background as they're not killed as well, and this could cause output spew
or future build failures.
This situation is handled by default on Unix because ctrl-c will end up sending
a signal to the entire *process group*, which kills everything, but on Windows
we're not as lucky (just Cargo itself is killed). By using job objects on
Windows we can ensure that the entire tree dies instead of just the top Cargo
process.
Alex Crichton [Mon, 8 Feb 2016 19:28:53 +0000 (11:28 -0800)]
Use job objects on windows for ctrl-c to work
Currently it's somewhat surprising if you're using cargo and it's then ctrl-c'd.
The child processes that Cargo spawned are likely to still be running around in
the background as they're not killed as well, and this could cause output spew
or future build failures.
This situation is handled by default on Unix because ctrl-c will end up sending
a signal to the entire *process group*, which kills everything, but on Windows
we're not as lucky (just Cargo itself is killed). By using job objects on
Windows we can ensure that the entire tree dies instead of just the top Cargo
process.
bors [Fri, 5 Feb 2016 20:52:49 +0000 (20:52 +0000)]
Auto merge of #2359 - matklad:metadata-no-deps, r=alexcrichton
closes #2356. The output is not exactly the same as with `read-manifest`, because I wanted to include the `version` field.
Tests and implementation is a copy-paste from `read-manifest` except that [this line](https://github.com/rust-lang/cargo/blob/master/src/bin/read_manifest.rs#L36) is omited, because `root_package` [does update anyway](https://github.com/rust-lang/cargo/blob/master/src/cargo/sources/path.rs#L51).
bors [Fri, 5 Feb 2016 18:32:07 +0000 (18:32 +0000)]
Auto merge of #2335 - fpgaminer:config-target, r=alexcrichton
Fixed #2332.
This PR adds `build.target` to the Cargo config file, which behaves in the same way as passing `--target` to Cargo. Example `.cargo/config`:
```
[build]
target = "thumbv6m-none-eabi"
```
Similar to how `--jobs` overrides `build.jobs`, `--target` will override `build.target`.
I added documentation to `config.md`, and a test to `test_cargo_cross_compile.rs`. I couldn't get cross compile working on my machine for `cargo test`. Hopefully travis passes it.
This is my first PR against Cargo; sorry if I missed any procedures.
bors [Fri, 5 Feb 2016 17:28:04 +0000 (17:28 +0000)]
Auto merge of #2357 - matklad:no-more-warnings-in-tests, r=alexcrichton
Warnings from unrelated tests can be a little disturbing. Maybe we should be stricter about them?
You can always temporary `#![allow(unused, warnings)]` in the module you are writing if you are in the middle of a new development and don't want the compiler putting a spoke in the wheel.
bors [Tue, 2 Feb 2016 21:12:37 +0000 (21:12 +0000)]
Auto merge of #2355 - alexcrichton:fix-ordering-bug, r=brson
Cargo needs to ensure that if a build script prints a `-L` path that it's the
first `-L` path passed to the compiler. That way the build script can be sure
that any output it generated is the first to be considered by the compiler.
Alex Crichton [Tue, 2 Feb 2016 19:42:57 +0000 (11:42 -0800)]
Fix DAG ordering of passed -L flags
Cargo needs to ensure that if a build script prints a `-L` path that it's the
first `-L` path passed to the compiler. That way the build script can be sure
that any output it generated is the first to be considered by the compiler.
bors [Tue, 2 Feb 2016 04:52:21 +0000 (04:52 +0000)]
Auto merge of #2352 - alexcrichton:new-snapshots, r=alexcrichton
The current snapshot is *super* old (305 days), but as of a few minutes ago it looks like all builds are going to fail with:
```
Updating registry `https://github.com/rust-lang/crates.io-index`
Failed to parse registry's information for: url
Caused by:
the given version requirement is not implemented, yet
```
I believe this is because ages ago the semver library wasn't quite fully implemented. The [most recently published url crate](https://crates.io/crates/url/0.5.4) has a version requirement that looks like `>= foo, < bar` which I believe was implemented at some point in the last year.
As a result if we want to keep building Cargo on bors we'll have to upgrade the snapshot, so this does so! For now just pick the absolute newest Cargo to run with and we reset the counters!
bors [Mon, 1 Feb 2016 21:13:28 +0000 (21:13 +0000)]
Auto merge of #2344 - Stebalien:upgrade-term, r=alexcrichton
This PR re-upgrades term to 0.4.3. Cargo now detects whether or not
color is supported immediately after creating the TerminfoTerminal.
Backstory:
Before v0.4, term used to return `Ok(true)` if something succeeded,
`Ok(false)` if the operation was unsupported, and `Err(io::Error)` if there
was an IO error. Now, it returns `Ok(())` if the operation succeeds and
`Err(term::Error)` if the operation fails. If the operation is unsupported,
it returns `Err(term::Error::NotSupported)`. This means that, if `op` is
unsupported, `try!(term.op())` will now return an error instead of silently
failing (well, return false but that's effectively silent).
Steven Allen [Mon, 1 Feb 2016 01:03:14 +0000 (20:03 -0500)]
Detect whether or not the terminal supports color.
Before v0.4, term used to return `Ok(true)` if something succeeded,
`Ok(false)` if the operation was unsupported, and `Err(io::Error)` if
there was an IO error. Now, it returns `Ok(())` if the operation
succeeds and `Err(term::Error)` if the operation fails. If the operation
is unsupported, it returns `Err(term::Error::NotSupported)`. This means
that, if `op` is unsupported, `try!(term.op())` will now return an error
instead of silently failing (well, return false but that's effectively
silent).
(Unfortunately I do not have a suggestion for how to make a unit test for this problem; doing so would require putting in a bit more effort than I have time for at the moment.)
(Unfortunately I do not have a suggestion for how to make a unit test
for this problem; doing so would require putting in a bit more effort
than I have time for at the moment.)
bors [Fri, 29 Jan 2016 22:15:35 +0000 (22:15 +0000)]
Auto merge of #2330 - rillian:fixes, r=alexcrichton
std::slice::SliceConcatExt::connect() was deprecated in 1.3.0
and renamed to join(). Now that 1.6.0 is the stable release,
we can transition to the newer method name.
Ralph Giles [Fri, 29 Jan 2016 21:27:20 +0000 (13:27 -0800)]
Replace deprecated slice::connect with slice::join.
std::slice::SliceConcatExt::connect() was deprecated in 1.3.0
and renamed to join(). Now that 1.6.0 is the stable release,
we can transition to the newer method name.
bors [Fri, 29 Jan 2016 04:10:44 +0000 (04:10 +0000)]
Auto merge of #2327 - alexcrichton:ustar-archives, r=alexcrichton
The tar::Builder type by default will build GNU archives, but
unfortunately we force it here to use UStar archives instead. The
UStar format has more limitations on the length of path name that it
can encode, so it's not quite as nice to use.
Older cargos, however, had a bug where GNU archives were interpreted
as UStar archives. This bug means that if we publish a GNU archive
which has fully filled out metadata it'll be corrupt when unpacked by
older cargos.
Hopefully in the future after enough cargos have been running around
with the bugfixed tar-rs library we'll be able to switch this over to
GNU archives, but for now we'll just say that you can't encode paths
in archives that are *too* long.
Alex Crichton [Fri, 29 Jan 2016 04:07:56 +0000 (20:07 -0800)]
Build UStar archives by default
The tar::Builder type by default will build GNU archives, but
unfortunately we force it here to use UStar archives instead. The
UStar format has more limitations on the length of path name that it
can encode, so it's not quite as nice to use.
Older cargos, however, had a bug where GNU archives were interpreted
as UStar archives. This bug means that if we publish a GNU archive
which has fully filled out metadata it'll be corrupt when unpacked by
older cargos.
Hopefully in the future after enough cargos have been running around
with the bugfixed tar-rs library we'll be able to switch this over to
GNU archives, but for now we'll just say that you can't encode paths
in archives that are *too* long.
bors [Mon, 25 Jan 2016 21:50:36 +0000 (21:50 +0000)]
Auto merge of #2319 - alexcrichton:compat-12, r=brson
There hasn't actually ever been a request to maintain compatibility with older
stable Rust versions, and it's becoming a bit of a maintenance burden, so just
switch CI to run on stable Rust.
Alex Crichton [Mon, 25 Jan 2016 20:52:23 +0000 (12:52 -0800)]
Remove 1.2.0 from .travis.yml
There hasn't actually ever been a request to maintain compatibility with older
stable Rust versions, and it's becoming a bit of a maintenance burden, so just
switch CI to run on stable Rust.
bors [Mon, 25 Jan 2016 17:56:00 +0000 (17:56 +0000)]
Auto merge of #2196 - matklad:metadata2, r=alexcrichton
Most of the work was done by @dan-t in #1225 and by @winger in #1434
Fixes #2193
I failed to properly rebase previous attempts so I just salvaged this from bits and pieces.
@alexcrichton are you sure that the default format should be TOML? I think that TOML is more suitable for humans, and JSON is better (at the moment at least) for tools. Maybe we should default to ~~TOML~~ JSON?
bors [Sun, 24 Jan 2016 18:42:32 +0000 (18:42 +0000)]
Auto merge of #2081 - vi:cargo_init, r=alexcrichton
Implement `cargo init` command and appropriate tests ( #21).
Features:
* Working like `cargo new` if there are no files in current directory
* Auto-detection of `--bin`
* Auto-detection of already existing VSC and appending to respecive ignore file
* Appending of appropriate `[lib]` or `[[bin]]` section to `Cargo.toml` in case of some non-standard source locations
Concerns:
* I'm not experienced in Rust + lazy => code looks poorer compared to the rest Cargo code
* The test don't cover 100% of functions
* Project consisting of both binary and library is not handled
* Many deviations from [previously proposed algorithm](https://github.com/rust-lang/cargo/pull/2008#issuecomment-145607870)
When non-existing directory is provided as argument, it
works just like "cargo new".
When existing directory is used, it may also create template
source file like "cargo new" or may find and use existing
source code for Cargo.toml.
Squashed commit of the following:
cargo init: Supply USER envvar for one test
cargo init: Other message when Cargo.toml already exists
cargo init: Resolve conflict after with #2257
fix minor issues
cargo new/init: Simplify error handling code in entry points
cargo new/init: Better message for invalid characters in name
cargo init: fix minor issues in test
cargo init: Avoid excessive builds in the test
cargo init: minor fixes
cargo init: Skip no_filename test on Windows
cargo init: Implement better error message for bin name clash
cargo init: minor fixes
cargo init: handle "/" path
cargo init: Actualise
cargo new: Fix upper case error message in test
cargo init: Remove paths::{file,directory}_already_exists
fix uppper-case error messages
cargo init: Fix minor issues per diff comments
cargo init: Change binary handling
cargo init: Move multiple lib error detection away from mk
cargo init: Support optional path argument
cargo init: Fix minor issues per Github comments
cargo init: Fix complaint from tests/check-style.sh
cargo init: Handle projects with multiple mains
cargo init: Major refactor, multi-target projects
cargo init: Add Cargo.lock unconditionally
cargo init: Fix complains from tests/check-style.sh
cargo init: Tests for handling VCS
cargo init: Handle VCS
cargo init: work in progress
cargo init: Deduplicate some things between new and init
cargo init: Auto-detection of --bin
cargo init: work in progress...
cargo init: Fix tests and allow explicit --vcs
cargo init: intermediate refactor
cargo init: First sketch of implementation
cargo init: Preliminary test
cargo init: first stub
See
https://github.com/vi/cargo/tree/cargo_init_unsquashed
for individual commits
bors [Sat, 23 Jan 2016 00:21:03 +0000 (00:21 +0000)]
Auto merge of #2307 - alexcrichton:readme, r=brson
Running `cargo build` should work just fine to build cargo as well as not
running the python script to download rustc itself. Now that Cargo runs on
stable (and a pretty old stable) most Rust installations should "Just Work" to
build Cargo.
Alex Crichton [Sat, 23 Jan 2016 00:09:17 +0000 (16:09 -0800)]
Add more info to README about compiling
Running `cargo build` should work just fine to build cargo as well as not
running the python script to download rustc itself. Now that Cargo runs on
stable (and a pretty old stable) most Rust installations should "Just Work" to
build Cargo.