* Updates git2-rs back to 0.3 now that the distribution issue on OSX has been
fixed.
* Updates libgit2-sys to using the `cmake` crate so building with VS 2015 can
work.
* Update pkg-config to totally disable it on MSVC (basically guaranteed to never
work)
Unfortunately this flew past on the bots because we didn't built on one of the
10.7 bots, but it looks like libgit2 doesn't currently build on OSX 10.7 so
we'll have to wait until that's fixed to update.
This commit adds support to Cargo to pass `--cap-lints allow` to all upstream
dependencies instead of `-A warings`. This should serve the same purpose of
suppressing warnings in upstream dependencies as well as preventing widespread
breakage whenever a change to a lint is introduced in the compiler.
Along the way, this also removes the ability to specify `[[lib]]` targets while
getting warnings. While we're at it remove nearly all unstable features that
Cargo is depending on as well!
Previously --extern was passed for *all* upstream dependencies, causing
conflicts if some had duplicate names. Now cargo only passes --extern for
libraries that were built including immediate dependencies. Cargo also
additionally now properly passes `-L dependency=` instead of just a plain `-L`.
Closes#1449
This commit is a complete overhaul of how Cargo handles compilation profiles
internally. The external interface of Cargo is not affected by this change.
Previously each Target had a Profile embedded within it. Conceptually a Target
is an entry in the manifest (a binary, benchmark, etc) and a Profile controlled
various flags (e.g. --test, -C opt-level, etc). Each Package then contained many
profiles for each possible compilation mode. For example a Package would have
one target for testing a library, benchmarking a library, documenting a library,
etc. When it came to building these targets, Cargo would filter out the targets
listed to determine what needed to be built.
This filtering was largely done based off an "environment" represented as a
string. Each mode of compilation got a separate environment string like `"test"`
or `"bench"`. Altogether, however, this approach had a number of drawbacks:
* Examples in release mode do not currently work. This is due to how examples
are classified and how release mode is handled (e.g. the "release" environment
where examples are meant to be built in the "test" environment).
* It is not trivial to implement `cargo test --release` today.
* It is not trivial to implement `cargo build --bin foo` where *only* the binary
`foo` is built. The same is true for examples.
* It is not trivial to add selective building of a number of
binaries/examples/etc.
* Filtering the list of targets to build has some pretty hokey logic that
involves pseudo-environments like "doc-all" vs "doc". This logic is duplicated
in a few places and in general is quite brittle.
* The TOML parser greatly affects compilation due to the time at which profiles
are generated, which seems somewhat backwards.
* Profiles must be overridden, but only partially, at compile time becuase only
the top-level package's profile is applied.
In general, this system just needed an overhaul. This commit made a single
change of separating `Profile` from `Target` and then basically hit `make` until
all the tests passed again. The other large architectural changes are:
* Environment strings are now entirely gone.
* Filters are implemented in a much more robust fashion.
* Release mode is now handled much more gracefully.
* The unit of compilation in the backend is no longer (package, target) but
rather (package, target, profile). This change had to be propagated many
location in the `cargo_rustc` module.
* The backend does not filter targets to build *at all*. All filtering now
happens entirely in the frontend.
I'll test issues after this change lands, but the motivation behind this is to
open the door to quickly fixing a number of outstanding issues against Cargo.
This change itself is not intended to close many bugs.
When probing a repository for files that should be considered as inputs for a
build script we should just skip submodules that haven't been checked out
instead of throwing an error.
Closes#1248
This helps get nice pretty stack traces which terminate when we get into the
weeds of errors but still present relevant contextual information when Cargo
isn't run with --verbose
This commit started out by moving the hash map of configuration values into
`Config` and then removing all calls to config::all_configs in favor of taking a
`&Config` argument. This initial step was taken to prevent reloading
configuration many times from disk, but it also provides a nice house for
configuration to be loaded from.
The commit snowballed into purging `MultiShell` as an argument all over the
place and passing around `Config` instead. Along the way a few other breaking
changes were made:
* The `config_for_key` and `config_list` subcommands have been removed. These
commands are not ready to be stabilized and need some more work. In general
the `cargo config` system needs to be cleaned out and built back up with a new
interface, at which point these subcommands can return.
* The old and deprecated behavior of `cargo update foo` has been removed.
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.
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).
Closes#1069
I'm a bit shaky on the profile.rs changes (`thread_local!` and `RefCell`
relplacing `local_data_key!`), do make sure I haven't royally screwed
something up there.
Note that I haven't sucessfully run the various test_cargo_cross_compile
tests as I don't have an i686-unknown-linux-gnu rustc sitting around.
When applying the lockfile to a resolve graph, we need to take into account that
the listed source of dependencies can change over time, in which case we cannot
lock to the previous version but instead need to continue onwards with updating
the listed source.
Closes#951
With the recent resolve rewrite, `cargo update -p foo` would only update one
package in a git repository, even if the repository provided many packages.
Cargo does not currently support depending on the same git repository source
with different precise revisions, and this would cause errors down the line
depending on what happened.
This adds a fix to the `resolve_with_previous` method to ensure that any
non-registry sources being updated will not have any locked packages inside them
which would result in an invalid lockfile.
When updating a source with multiple packages, the registry will lazily discover
both the precise and imprecise versions of the source at some point. Previously
the source would be updated depending on which was discovered first, but this
commit adds logic to understand that if an imprecise version is discovered after
a precise version then the imprecise version should be favored (because it will
always trigger an update).
This needs to understand, however, that if `cargo update --precise` is used that
those sources should not be updated again, so the sources treated in
`add_sources` are considered "special" in the sense that they're locked and will
not be updated again.
This method shouldn't be necessary as it should be possible to simply add all
sources known in the lockfile to a package registry, and
core::{resolve, registry} should take care of weeding them out if necessary.
In the process of doing so, this actually ends up fixing a problem with
rewriting a dependency to a new one which shares transitive deps. Previously all
the transitive deps were updated, but now the transitive deps remain locked at
where they were previously locked.
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*.
Closes#697
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.
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.
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.
Closes#483
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).
cc #537
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.
Closes#484
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.
Closes#613
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.
Closes#613
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.
Closes#490Closes#496
