Alex Crichton [Wed, 15 Oct 2014 23:18:43 +0000 (16:18 -0700)]
Add a metadata section to the lockfile
In terms of future compatibility, Cargo may wish to add more information to
lockfiles in the future. For example, the minimum required Rust version may one
day be encoded into a lockfile.
One of the major goals of a lockfile is for it to rarely change, and when it
does change the diffs should be minimal. In terms of adding more information to
the lockfile in the future, this presents a problem for older Cargo clients:
1. Cargo 2.0 adds a minimum required version of rust under the metadata.rustc
key of the lockfile.
2. Cargo 1.0 is then used to update the `foo` dependency in the lockfile. When
regenerating the lockfile, Cargo 1.0 discards the metadata inserted by Cargo
2.0.
In order to future-proof ourselves in allowing new metadata in the future, Cargo
is growing support now for transporting an opaque payload of metadata from one
version of a lockfile to a new versions. This should solve the problem presented
above.
This metadata section is designed to be safely ignored by older Cargo versions
(may just have some surprising behavior), while still allowing newer versions of
Cargo to process the data. For example Cargo 2.0 would gracefully fail on an
out-of-date rustc, while Cargo 1.0 may just present an obscure error message.
bors [Wed, 22 Oct 2014 19:14:21 +0000 (19:14 +0000)]
auto merge of #717 : alexcrichton/cargo/souped-up-resolve, r=wycats
This series of commits is rebased on top of https://github.com/rust-lang/cargo/pull/712 to avoid conflicts, and it adds the ability to solve version constraints as part of the resolution process. This is a critical step forward in bringing the registry online as it makes it possible for cargo to figure out what to do in the face of many uploaded versions of a package to the registry.
Alex Crichton [Fri, 17 Oct 2014 19:23:10 +0000 (12:23 -0700)]
Avoid visiting deps too often in resolve
If we're activating an already-active version of a dependency, then there's no
need to actually recurse into it. Instead, we can skip it if we're not enabling
any extra features in it to avoid extraneous recursion.
Alex Crichton [Fri, 17 Oct 2014 18:50:18 +0000 (11:50 -0700)]
Continue reducing clone costs
Share the `visited` hash set among all contexts, just be sure to maintain it
across failures. Also put all Summary structures into an `Rc` as they're cloned
quite frequently.
Alex Crichton [Fri, 17 Oct 2014 18:48:57 +0000 (11:48 -0700)]
Make SourceId cheap to clone
Like PackageId, these are cloned quite often, so this moves them into an Arc to
make them cheap to clone. This also removes the public fields in favor of
accessors.
Alex Crichton [Fri, 17 Oct 2014 18:47:33 +0000 (11:47 -0700)]
Make PackageId cheap to clone
These are cloned a massive number of times during resolution, so let's make them
much cheaper to clone with an Arc. This uses Arc instead of Rc because the
fiddly bits in job_queue have a PackageId cross task boundaries for parallelism.
Alex Crichton [Fri, 17 Oct 2014 15:17:17 +0000 (08:17 -0700)]
Implement resolution of version requirements
This commit extends the support in cargo's resolver to start resolving packages
with multiple versions as well as package requirements. This is a crucial step
forward when impelmenting the cargo registry as multiple versions will be
uploaded to the registry quite quickly!
This implements a fairly naive solution which should at least help cargo get out
the gates initially. This impelments a depth-first-search of the pacakage
dependency graph with a few sorting heuristics along the way to help out
resolution as it goes along.
Resolution errors will likely improve over time, but this commit does make an
effort to try to get some good error messages right off the bat.
bors [Fri, 17 Oct 2014 23:03:03 +0000 (23:03 +0000)]
auto merge of #720 : alexcrichton/cargo/no-more-plugins, r=brson
It's looking more likely like plugins will not make it into the stable channel
of Rust, so this commits removes Cargo's personal dependence on the two
plugin-based pieces of functionality it was using:
1. Uses of the `regex!` macro now go through `Regex::new`.
2. Uses of the `docopt!` macro now go through `deriving(Decodable)` instead.
bors [Fri, 17 Oct 2014 22:48:18 +0000 (22:48 +0000)]
auto merge of #711 : alexcrichton/cargo/issue-708, r=brson
I can't quite remember why this ifdef is present to silently run `make` as a
normal user, and it doesn't seem to work if `make install` is run while as root,
so I'm just removing it and requiring that `make` is run before `make install`
unconditionally.
Alex Crichton [Fri, 17 Oct 2014 22:04:13 +0000 (15:04 -0700)]
Remove dependence on various plugins
It's looking more likely like plugins will not make it into the stable channel
of Rust, so this commits removes Cargo's personal dependence on the two
plugin-based pieces of functionality it was using:
1. Uses of the `regex!` macro now go through `Regex::new`.
2. Uses of the `docopt!` macro now go through `deriving(Decodable)` instead.
bors [Fri, 17 Oct 2014 22:22:39 +0000 (22:22 +0000)]
auto merge of #712 : alexcrichton/cargo/issue-633, r=brson
As pointed in #633, it's currently not possible for a package to reexport the
feature of another package due to the limitations of how features are defined.
This commit adds support for this ability by allowing features of the form
`foo/bar` in the `features` section of the manifest. This form indicates that
the dependency `foo` should have its `bar` feature enabled. Additionally, it is
not required that `foo` is an optional dependency.
This does not allow features of the form `foo/bar` in a `[dependencies]`
features section as dependencies shouldn't be enabling features for other
dependencies.
At the same time, this passes through features to build commands to solve a few more issues.
Closes #97
Closes #601 (this is an equivalent solution for that problem)
Closes #633
Closes #674
Alex Crichton [Thu, 16 Oct 2014 17:09:39 +0000 (10:09 -0700)]
Allow reexporting of features between packages
As pointed in #633, it's currently not possible for a package to reexport the
feature of another package due to the limitations of how features are defined.
This commit adds support for this ability by allowing features of the form
`foo/bar` in the `features` section of the manifest. This form indicates that
the dependency `foo` should have its `bar` feature enabled. Additionally, it is
not required that `foo` is an optional dependency.
This does not allow features of the form `foo/bar` in a `[dependencies]`
features section as dependencies shouldn't be enabling features for other
dependencies.
Alex Crichton [Thu, 16 Oct 2014 15:36:57 +0000 (08:36 -0700)]
Require `make` is run before `make install`
I can't quite remember why this ifdef is present to silently run `make` as a
normal user, and it doesn't seem to work if `make install` is run while as root,
so I'm just removing it and requiring that `make` is run before `make install`
unconditionally.
bors [Tue, 14 Oct 2014 23:44:54 +0000 (23:44 +0000)]
auto merge of #700 : alexcrichton/cargo/issue-697, r=brson
When a source has multiple crates inside of it, `cargo update -p foo` would
previously not actually update anything because the extra crates were continuing
to lock the source to the same revision. This change updates the "avoid me"
logic to avoid *sources*, not *packages*.
bors [Tue, 14 Oct 2014 21:44:58 +0000 (21:44 +0000)]
auto merge of #706 : kballard/cargo/patch-1, r=alexcrichton
`$(OUT_DIR)` may contain spaces, so it needs to be quoted. It also needs to be expanded by the shell, not by `make`, or any quotes/backslashes in the value will cause problems.
Kevin Ballard [Tue, 14 Oct 2014 21:30:17 +0000 (14:30 -0700)]
Tweak native-build.md example
`$(OUT_DIR)` may contain spaces, so it needs to be quoted. It also needs to be expanded by the shell, not by `make`, or any quotes/backslashes in the value will cause problems.
bors [Tue, 14 Oct 2014 19:59:57 +0000 (19:59 +0000)]
auto merge of #698 : eagleflo/cargo/new-invalid-characters, r=alexcrichton
Crate names have tight restrictions in Rust. `cargo new` should not allow invalid characters in crate names, as such crates will just fail to compile later on.
This check is based on the one found in rustc's `validate_crate_name` (https://github.com/rust-lang/rust/blob/master/src/librustc/metadata/creader.rs#L185-L189).
bors [Mon, 13 Oct 2014 23:45:00 +0000 (23:45 +0000)]
auto merge of #703 : alexcrichton/cargo/doc.crates.io, r=alexcrichton
The actual crates.io domain will become the registry itself, but the
auto-generated documentation from this repository will continue to be available
at the doc.crates.io domain.
In the meantime, we've set up redirects from crates.io and www.crates.io to
doc.crates.io and the github-pages site will now be doc.crates.io
Alex Crichton [Mon, 13 Oct 2014 23:31:33 +0000 (16:31 -0700)]
Move documentation to doc.crates.io
The actual crates.io domain will become the registry itself, but the
auto-generated documentation from this repository will continue to be available
at the doc.crates.io domain.
In the meantime, we've set up redirects from crates.io and www.crates.io to
doc.crates.io and the github-pages site will now be doc.crates.io
Alex Crichton [Mon, 13 Oct 2014 16:54:08 +0000 (09:54 -0700)]
Fix updating sources with more than one crate
When a source has multiple crates inside of it, `cargo update -p foo` would
previously not actually update anything because the extra crates were continuing
to lock the source to the same revision. This change updates the "avoid me"
logic to avoid *sources*, not *packages*.
bors [Thu, 9 Oct 2014 19:44:57 +0000 (19:44 +0000)]
auto merge of #682 : vhbit/cargo/empty-features, r=alexcrichton
For automation it should be no difference between invocations
of `--features "feat1 feat2 feat3"` and `--features ""`.
The problem is that in the latter case `docopt` sets flag_feature to vec![""]
Could be solved on 3 different levels:
- patching `docopt` to treat empty string for a Vec<String> flag
as empty vec. Although I can't imagine that in some place it
might be required to treat empty string as vector of empty
strings it is might have its own use
- filtering flags_feature right after parsing command line and
before passing further. It means it should be fixed in at
least 4 different places now and may be forgotten in future
- filtering empty string feature while resolving - perhaps
the easiest and more universal solution, implemented in this
patch
Valerii Hiora [Wed, 8 Oct 2014 05:54:16 +0000 (08:54 +0300)]
Allow to invoke Cargo commands with empty features
For automation it should be no difference between invocations
of `--features "feat1 feat2 feat3"` and `--features ""`.
The problem is that in the latter case `docopt` sets flag_feature to vec![""]
Could be solved on 3 different levels:
- patching `docopt` to treat empty string for a Vec<String> flag
as empty vec. Although I can't imagine that in some place it
might be required to treat empty string as vector of empty
strings it is might have its own use.
- filtering flags_feature right after parsing command line and
before passing further. It means it should be fixed in at
least 4 different places now and may be forgotten in future.
- filtering empty string feature while resolving - perhaps
the easiest and more universal solution, implemented in this
patch.
bors [Tue, 7 Oct 2014 03:07:37 +0000 (03:07 +0000)]
auto merge of #671 : alexcrichton/cargo/issue-668, r=brson
Examples are classified as binaries, but do not have the `test` flag set on
their Profile. They do, however, have their environment set to `test`. Be sure
to place them into the `tests` bucket so they have development dependencies
available for their compilation.
Alex Crichton [Mon, 6 Oct 2014 03:00:42 +0000 (20:00 -0700)]
Make sure dev-deps are compiled for examples
Examples are classified as binaries, but do not have the `test` flag set on
their Profile. They do, however, have their environment set to `test`. Be sure
to place them into the `tests` bucket so they have development dependencies
available for their compilation.
bors [Mon, 6 Oct 2014 23:00:04 +0000 (23:00 +0000)]
auto merge of #663 : alexcrichton/cargo/issue-648, r=brson
This means that if a project has a file with a space in the name it will
properly have its freshness calculated as opposed to always having it as a
candidate to be rebuilt.
bors [Mon, 6 Oct 2014 20:30:07 +0000 (20:30 +0000)]
auto merge of #675 : alexcrichton/cargo/fix-selective-test, r=brson
Now that we have selective testing, this no longer makes any sense and all
queries to the path layout need to be based on the package being queried for.
This removes the primary flag from the Context, and requires that the `layout`
method have a local Package available
Alex Crichton [Mon, 6 Oct 2014 18:27:16 +0000 (11:27 -0700)]
Remove the notion of "primary" from Context
Now that we have selective testing, this no longer makes any sense and all
queries to the path layout need to be based on the package being queried for.
This removes the primary flag from the Context, and requires that the `layout`
method have a local Package available
bors [Mon, 6 Oct 2014 03:15:06 +0000 (03:15 +0000)]
auto merge of #667 : jakerr/cargo/help-help, r=alexcrichton
This adds a dummy help command so that it's usage can be documented with docopt! This lets `cargo help help` work.
Also adds help flags to all of the subcommands that were missing them. Without
that `cargo help sub-command` shows Invalid Argument before the usage text.
bors [Mon, 6 Oct 2014 02:30:06 +0000 (02:30 +0000)]
auto merge of #670 : bkoropoff/cargo/unused-everywhere, r=alexcrichton
I'm not sure what changed, but unused value lints were popping up everwhere when I tried to build today.
This turns on the `if let` feature since it allows rewriting a lot of calls to `Option::map` that were only being used for their side effects into a clean form. Cargo seems as good of a place as any to dogfood it.
Jake Kerr [Sun, 5 Oct 2014 07:13:43 +0000 (16:13 +0900)]
Let the help command work consistently everywhere
This adds a dummy help command so that it's usage can be documented with docopt!
Also adds help flags to all of the subcommands that were missing them. Without
that `cargo help sub-command` shows Invalid Argument before the usage text.
Alex Crichton [Fri, 3 Oct 2014 01:37:27 +0000 (18:37 -0700)]
Parse escaped spaces in makefile dependencies
This means that if a project has a file with a space in the name it will
properly have its freshness calculated as opposed to always having it as a
candidate to be rebuilt.
bors [Fri, 3 Oct 2014 01:57:14 +0000 (01:57 +0000)]
auto merge of #630 : alexcrichton/cargo/issue-432, r=brson
This is a series of commits which culminates in fixing #432, fixing a number of other related issues along the way. The biggest user-facing fix here is that if you run `cargo build` followed by `cargo test` your library will no longer be rebuilt if you have dev-dependencies.
Alex Crichton [Wed, 24 Sep 2014 05:12:01 +0000 (22:12 -0700)]
Fix the dependency graph with root pkg cycles
If the root package ended up depending on itself through some development
dependency (technically not a cycle), then the resolve phase would currently
overwrite some previous result, destroying the progress. By registering the root
package as seen early on this prevents the overwriting from happening and
instead appending happens.
Alex Crichton [Wed, 24 Sep 2014 05:10:32 +0000 (22:10 -0700)]
Allow "cycles" through dev-deps
Development dependencies can never be the root of a cycle because nothing
depends on a development dependency, so there's no need to track the start of a
cycle at the edge going out to a development dependency.
If a cycle is later detected, it will still be reported.
Alex Crichton [Tue, 23 Sep 2014 22:22:14 +0000 (15:22 -0700)]
Refine dependencies on dev-deps
Currently whenever a dev-dep is brought in to the build process the entire
library is rebuilt, but this is just unnecessary recompilation because the
library *can't* depend on the dev-dep.
This commit refines the dependency graph so the lib stage only depends on
transitive dependencies (non-dev-deps), and a new stage for tests was added
which depends on the packages libraries *and* the dev-deps. This way only the
test are rebuilt when dev-deps change, not libraries.
bors [Thu, 2 Oct 2014 20:07:47 +0000 (20:07 +0000)]
auto merge of #659 : alexcrichton/cargo/licenseing, r=brson
This follows #656 by mentioning OpenSSL in the README, as well as install all
license files on installation. A hand-generated LICENSE-THIRD-PARTY is also
included.
Closes #656
This also approaches #657 by mentioning that we have GPL software in the README.
Cargo will hopefully support a more complete "all source" distribution in the
future, but at this time there is not an easy way to generate a complete source
tarball via cargo.
Alex Crichton [Thu, 2 Oct 2014 19:40:33 +0000 (12:40 -0700)]
Install materials to comply with upstream licenses
This follows #656 by mentioning OpenSSL in the README, as well as install all
license files on installation. A hand-generated LICENSE-THIRD-PARTY is also
included.
Closes #656
This also approaches #657 by mentioning that we have GPL software in the README.
Cargo will hopefully support a more complete "all source" distribution in the
future, but at this time there is not an easy way to generate a complete source
tarball via cargo.
auto merge of #628 : alexcrichton/cargo/issue-537, r=brson
This is rebased on https://github.com/rust-lang/cargo/pull/617 as I wanted to use one of the functions added in the patch. Otherwise the details are in the commits.
Alex Crichton [Sat, 27 Sep 2014 04:24:31 +0000 (21:24 -0700)]
Deprecate `cargo update foo`
To maintain consistency with `cargo {build,test,bench,clean}` the `update`
subcommand now takes a specific package via the `-p` argument instead of as a
positional argument.
Alex Crichton [Wed, 24 Sep 2014 01:10:27 +0000 (18:10 -0700)]
Add cargo {test,bench} -p <spec>
This functionality allows running tests and benchmarks on any upstream
dependencies in the dependency graph. This is most useful for path sources all
developed in tandem (see Servo for instance).
In terms of built artifacts, this will actually preserve as many artifacts as
possible. That means that if you test a low-level dependency with the high-level
artifacts already built, the high-level artifacts will not get removed. This
means that it's possible to accidentally have a low-level dependency to depend
on a higher level one just because it's lib is picked up via -L, but this is
generally a necessary evil to get testing to not rebuild packages too often.