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
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.
Alex Crichton [Tue, 23 Sep 2014 16:03:34 +0000 (09:03 -0700)]
Allow selectively cleaning packages
This adds a new argument to `cargo clean` which will enable selectively cleaning
particular packages. The command only cleans the package specified, no other
(not the dependencies of the package).
auto merge of #624 : alexcrichton/cargo/issue-484, r=wycats
This commit adds a flag, --precise, to cargo update. This flag is used to update
a dependency to precisely an exact revision (or branch) as part of an update
step. For git repositories the argument is some form of reference, while
registry packages this will be a version number.
The flag --precise forces a non-aggressive update and will fail if the
--aggresive flag is specified.
Alex Crichton [Tue, 23 Sep 2014 14:30:16 +0000 (07:30 -0700)]
Allow updating to a precise revision
This commit adds a flag, --precise, to cargo update. This flag is used to update
a dependency to precisely an exact revision (or branch) as part of an update
step. For git repositories the argument is some form of reference, while
registry packages this will be a version number.
The flag --precise forces a non-aggressive update and will fail if the
--aggresive flag is specified.
auto merge of #618 : alexcrichton/cargo/issue-593, r=wycats
This gives cargo a way to uniquely reference a package within a dependency graph. This is currently only used for `cargo update` and `cargo pkgid`, but this will extend in the future to possible configuration keys in the manifest, other commands like `clean`, etc.
auto merge of #614 : alexcrichton/cargo/issue-613, r=brson
As described in #613, this commit switches the semantics of `cargo update foo`
to updating *only* `foo`, not any of its dependencies. A new flag,
`--aggressive` was added to restore the old behavior.
The behavior of attempting to only unlock `foo`, and then if resolve fails
unlock all dependencies of `foo` is unimplemented as it's not super relevant
right now when the majority of dependencies are git dependencies and resolution
cannot fail for version-related reasons.
Alex Crichton [Sun, 21 Sep 2014 21:27:30 +0000 (14:27 -0700)]
Make `cargo update` more conservative.
As described in #613, this commit switches the semantics of `cargo update foo`
to updating *only* `foo`, not any of its dependencies. A new flag,
`--aggressive` was added to restore the old behavior.
The behavior of attempting to only unlock `foo`, and then if resolve fails
unlock all dependencies of `foo` is unimplemented as it's not super relevant
right now when the majority of dependencies are git dependencies and resolution
cannot fail for version-related reasons.
auto merge of #612 : alexcrichton/cargo/nocapture, r=wycats
There are some competing concerns when it comes to the output of compiling
dependencies:
* Not capturing anything leads to getting drowned in unrelated output
* Capturing requires coloration be compromised because of the way windows
terminal colors are implemented.
* Path dependencies are often developed in tandem with the rest of a package,
and capturing their output is not always desired.
To address these concerns, cargo previously captured output of dependent
compilations and then re-printed it to the screen if an error occurred. This
patch modifies the behavior to as follows:
* No output is captured. This preserves any coloration rustc provides.
* All dependencies are compiled with `-Awarnings`. This should suppress any
extraneous output from the compiler and it is considered a bug otherwise if
the compiler prints a warnings when `-Awarnings` is specified.
* All *path* dependencies (`path="..."`, overrides, etc) are *not* compiled with
`-Awarnings`. The reason for this is that you are always in control of these
packages and probably want to see warnings anyway.
Alex Crichton [Sun, 21 Sep 2014 17:22:46 +0000 (10:22 -0700)]
Stop capturing output of all dependencies
There are some competing concerns when it comes to the output of compiling
dependencies:
* Not capturing anything leads to getting drowned in unrelated output
* Capturing requires coloration be compromised because of the way windows
terminal colors are implemented.
* Path dependencies are often developed in tandem with the rest of a package,
and capturing their output is not always desired.
To address these concerns, cargo previously captured output of dependent
compilations and then re-printed it to the screen if an error occurred. This
patch modifies the behavior to as follows:
* No output is captured. This preserves any coloration rustc provides.
* All dependencies are compiled with `-Awarnings`. This should suppress any
extraneous output from the compiler and it is considered a bug otherwise if
the compiler prints a warnings when `-Awarnings` is specified.
* All *path* dependencies (`path="..."`, overrides, etc) are *not* compiled with
`-Awarnings`. The reason for this is that you are always in control of these
packages and probably want to see warnings anyway.
projects / cargo.git / log