bors [Wed, 14 Jan 2015 06:12:53 +0000 (06:12 +0000)]
Auto merge of #1165 - alexcrichton:issue-517, r=huonw
It's a little odd that Cargo only supports travis right now, and as #517 points
out it probably shouldn't be a top-level flag but rather a general "service
flag". Due to a lack of other services and the ease of adding your own travis
configuration, this commit removes the flag altogether for now. It can always be
added later when we've got some more impetus!
Alex Crichton [Wed, 14 Jan 2015 03:48:00 +0000 (19:48 -0800)]
Remove --travis from `cargo new`
It's a little odd that Cargo only supports travis right now, and as #517 points
out it probably shouldn't be a top-level flag but rather a general "service
flag". Due to a lack of other services and the ease of adding your own travis
configuration, this commit removes the flag altogether for now. It can always be
added later when we've got some more impetus!
bors [Sun, 11 Jan 2015 05:18:59 +0000 (05:18 +0000)]
Auto merge of #1148 - FlaPer87:change-home, r=alexcrichton
Users changing cargo's home directory expect it to be used as top path
instead of there being a `.cargo` hidden dir in it. There are some cases
following this pattern one of them is python's virtualenvwrapper, which
uses `WORK_HOME` as a home dir for everything.
This patch removes the extra `.cargo` and assumes that CARGO_HOME is the
real path a user wants to use as a homedir for cargo.
Flavio Percoco [Sat, 10 Jan 2015 23:44:12 +0000 (00:44 +0100)]
Don't use `.cargo` for custom CARGO_HOME
Users changing cargo's home directory expect it to be used as top path
instead of there being a `.cargo` hidden dir in it. There are some cases
following this pattern one of them is python's virtualenvwrapper, which
uses `WORK_HOME` as a home dir for everything.
This patch removes the extra `.cargo` and assumes that CARGO_HOME is the
real path a user wants to use as a homedir for cargo.
bors [Thu, 8 Jan 2015 20:52:43 +0000 (20:52 +0000)]
Auto merge of #1131 - alexcrichton:issue-880, r=brson
This fixes a number of bugs along the way:
* Submodules are now recursed into explicitly for packaging, fixing #943
* A whitelist has been implemented, fixing #880
* Git repos are now always used if there is a package that resides at the root,
not just if the current package resides at the root.
Alex Crichton [Tue, 6 Jan 2015 07:54:16 +0000 (23:54 -0800)]
Update how a PathSource is traversed for git repos
This fixes a number of bugs along the way:
* Submodules are now recursed into explicitly for packaging, fixing #943
* A whitelist has been implemented, fixing #880
* Git repos are now always used if there is a package that resides at the root,
not just if the current package resides at the root.
bors [Thu, 8 Jan 2015 19:35:06 +0000 (19:35 +0000)]
Auto merge of #1122 - alexcrichton:issue-1119, r=brson
It looks like tags don't always point to tag objects, but rather sometimes to
commits themselves. This tweaks the peeling logic for tags to find an *object*
first, and then peel to a commit, rather than finding a tag first and then
peeling.
bors [Tue, 6 Jan 2015 02:21:22 +0000 (02:21 +0000)]
Auto merge of #1123 - alexcrichton:issue-1037, r=alexcrichton
Now that the compiler supports the notion for a "dependency lookup path" Cargo
can specify this information to the compiler in order to prevent transitive
dependencies from being imported.
Wesley Wiser [Mon, 5 Jan 2015 01:59:43 +0000 (20:59 -0500)]
git option in config should be an enumeration
The option in ~/.cargo/config is now called `vcs` and has the following
options: "git", "hg", and "none". This corresponds to the options for
the --vcs argument to `cargo new`.
This also fixes detection for hg repositories. Previously, we only tried
to discover if the working directory was contained in a git repository.
If it was, we would skip creating a git repo. Now, we check if the
working directory is contained in either a git or mecurial repo. If it
is, we skip creating a new repo.
Alex Crichton [Sun, 4 Jan 2015 09:16:33 +0000 (01:16 -0800)]
Start using precise -L flags
Now that the compiler supports the notion for a "dependency lookup path" Cargo
can specify this information to the compiler in order to prevent transitive
dependencies from being imported.
bors [Mon, 5 Jan 2015 18:37:39 +0000 (18:37 +0000)]
Auto merge of #1126 - akiss77:pr-test_cargo_compile, r=alexcrichton
For two tests, the `Cargo.toml`s and the `cfg`s don't match. E.g., the first test expects a successful build on all linux platforms but its `toml` is prepared for Intel linuxes only. The second test is very similar.
Here, the `cfg`s are amended to match the `toml`s.
bors [Mon, 5 Jan 2015 16:36:00 +0000 (16:36 +0000)]
Auto merge of #1107 - tomaka:extract-commands-system, r=alexcrichton
With this change, the various commands in Cargo now build a `CommandPrototype` instead of a `ProcessBuilder`. This `CommandPrototype` is then passed to an object that implements the `CommandsExecution` trait, which executes them.
Ideally `CommandPrototype` would look like this:
```rust
enum CommandPrototype {
Rustc {
libraries: Vec<String>,
opt_level: uint,
input: Path,
... etc... (all the options that can be passed to rustc)
},
Rustdoc {
... (all the options that can be passed to rustdoc)
},
Custom {
cmd: ...,
env: ...,
}
}
```
...but that's a bit too much work for now (maybe in a follow-up).
What this enables is using the Cargo library to intercept the build commands and tweak them. I'm planning to write `cargo-emscripten` thanks to this change.
With this, one could also imagine embedding rustc and rustdoc directly inside cargo, if that is needed.
Alex Crichton [Sun, 4 Jan 2015 06:45:58 +0000 (22:45 -0800)]
Find objects instead of tags.
It looks like tags don't always point to tag objects, but rather sometimes to
commits themselves. This tweaks the peeling logic for tags to find an *object*
first, and then peel to a commit, rather than finding a tag first and then
peeling.
bors [Wed, 31 Dec 2014 21:10:58 +0000 (21:10 +0000)]
Auto merge of #1110 - brson:install, r=alexcrichton
This bug shouldn't actually cause any problems but it's a mistake that causes cargo's manifest to be stored in `/usr/lib/cargo` instead of `/usr/lib/rustlib`. People who upgrade will probably end up with an extra 'cargo' dir laying around...
Alex Crichton [Sun, 21 Dec 2014 23:19:44 +0000 (15:19 -0800)]
Clean up Cargo's util::errors module
This commit cleans up cargo's error module to reduce the duplication of
`CargoError` and the standard library's `Error` trait. The `CargoError` trait
remains, but only has one methods, `is_human`.
A number of other modifications were made:
* ChainError was altered to work over unboxed closures
* Wrap and Require were removed as they're duplicates of the ChainError
functionality.
* Many public error types are now private from util::errors as they're only
returned as boxed trait objects.
* The `concrete` was removed, all calls to `make_human` are now done through a
newtype `Human` wrapper.
* Cargo's custom `try!` macro was removed.
bors [Tue, 30 Dec 2014 02:28:49 +0000 (02:28 +0000)]
auto merge of #1100 : kballard/cargo/tweak-readme-install-instructions, r=alexcrichton
There's no need to promote the use of the `pwd` command when shells export the
current directory as `$PWD`. Using `$PWD` makes the commandline work in fish
as well. Additionally, quote the variable so it works properly even if the cwd
has a space in it.
bors [Tue, 30 Dec 2014 01:58:39 +0000 (01:58 +0000)]
auto merge of #1074 : alexcrichton/cargo/issue-1069, r=brson
This commit unifies the notion of a "git revision" between a SourceId and the
GitSource. This pushes the request of a branch, tag, or revision all the way
down into a GitSource so special care can be taken for each case.
This primarily was discovered by #1069 where a git tag's id is different from
the commit that it points at, and we need to push the knowledge of whether it's
a tag or not all the way down to the point where we resolve what revision we
want (and perform appropriate operations to find the commit we want).
Alex Crichton [Mon, 8 Dec 2014 18:46:07 +0000 (10:46 -0800)]
Refactor git rev handling infrastructure
This commit unifies the notion of a "git revision" between a SourceId and the
GitSource. This pushes the request of a branch, tag, or revision all the way
down into a GitSource so special care can be taken for each case.
This primarily was discovered by #1069 where a git tag's id is different from
the commit that it points at, and we need to push the knowledge of whether it's
a tag or not all the way down to the point where we resolve what revision we
want (and perform appropriate operations to find the commit we want).
Kevin Ballard [Mon, 29 Dec 2014 21:05:22 +0000 (13:05 -0800)]
Use "$PWD" instead of `pwd` in install instructions
There's no need to promote the use of the `pwd` command when shells
export the current directory as `$PWD`. Using `$PWD` makes the
commandline work in fish as well. Additionally, quote the variable so it
works properly even if the cwd has a space in it.
bors [Thu, 25 Dec 2014 00:13:40 +0000 (00:13 +0000)]
auto merge of #1085 : geomaster/cargo/master, r=alexcrichton
rust-lang/rust#19253 and rust-lang/rust@25f8051 have introduced changes
to the namespacing within the std::collections::hash_map, breaking some
of Cargo code which imported these.
rust-lang/rust@cf350ea, implementing changes proposed by RFC #344, have
also broken some code which relies on hash_set::SetItems (now renamed to
hash_set::Iter).
This PR fixes the incompatibilities: imports of
std::collections::hash_map::{Occupied, Vacant} have been replaced by
imports of std::collections::hash_map::Entry::{Occupied, Vacant} and one
instance where the SetItems has been used was replaced by the proper
usage of Iter.
David Davidović [Wed, 24 Dec 2014 20:40:14 +0000 (21:40 +0100)]
Temporary fix for tests
Two tests (test_with_deep_lib_dep and lib_with_standard_name) fail due
to a bug in rustdoc (see rust-lang/rust#20183) so temporarily changing
these so they pass. Be sure to change it back when the fix lands in the
current rust nightly
David Davidović [Wed, 24 Dec 2014 03:27:07 +0000 (04:27 +0100)]
Add Levenshtein distance implementation
Copy lev_distance.rs verbatim from Rust since str::lev_distance has been
deprecated by rust-lang/rust@9b99436 with no replacement and change code
to use it instead of the deprecated function
David Davidović [Wed, 24 Dec 2014 02:56:11 +0000 (03:56 +0100)]
Fix fn type mismatch error
rustc complains that we cannot assign two different fn's to a single
object within an if-else block. I was not able to figure out what causes
this; so deferring the execution of the particular function is a
reasonable fallback. Not very elegant and should be changed to something
with less boilerplate
David Davidović [Wed, 24 Dec 2014 02:53:42 +0000 (03:53 +0100)]
Handle from_utf8 new return type
As per rust-lang/rust@9b99436, the return type of from_utf8 has been
changed from Option to Result. Consequently, update code which relied on
this return type to work with Ok(...) and Err(...) instead of Some(...)
and None
David Davidović [Wed, 24 Dec 2014 02:45:46 +0000 (03:45 +0100)]
Migrate to rustc-serialize
As per rust-lang/rust@b04bc5c, move all Encodable and Decodable deriving
modes to RustcEncodable and RustcDecodable, and also extern the
rustc-serialize crate instead of the former serialize one.
David Davidović [Tue, 23 Dec 2014 02:15:56 +0000 (03:15 +0100)]
Update to rust master
rust-lang/rust#19253 and rust-lang/rust@25f8051 have introduced changes
to the namespacing within the std::collections::hash_map, breaking some
of Cargo code which imported these.
rust-lang/rust@cf350ea, implementing changes proposed by RFC #344, have
also broken some code which relies on hash_set::SetItems (now renamed to
hash_set::Iter).
This commit fixes the incompatibilities: imports of
std::collections::hash_map::{Occupied, Vacant} have been replaced by
imports of std::collections::hash_map::Entry::{Occupied, Vacant} and one
instance where the SetItems has been used was replaced by the proper
usage of Iter.
bors [Fri, 19 Dec 2014 21:45:29 +0000 (21:45 +0000)]
auto merge of #1067 : alexcrichton/cargo/fix-registry-update, r=alexcrichton
If a registry already knew about a package, but didn't know about newly
published version of a package, then the registry would occasionally not be
updated when it otherwise needed to be.
Alex Crichton [Fri, 19 Dec 2014 21:43:21 +0000 (13:43 -0800)]
Fix cases where a registry is not updated
If a registry already knew about a package, but didn't know about newly
published version of a package, then the registry would occasionally not be
updated when it otherwise needed to be.