This commit tweaks some metadata here and there to publish Cargo on crates.io.
* License fields are added to Cargo.tomls
* `registry` was renamed to `crates-io`
* API docs for the `cargo` crate are now generated via `make doc`
These commits provide the necessary support to get cargo working in the 32-bit MSVC context. Now that we've got 32-bit MSVC nightlies rolling we can add support!
This commit enables Cargo's bots to test cross builds between 32 and 64 bit
hosts. Many tests were fixed to work on Windows, and the 32-bit test case now
actually crosses to 64.
Cargo will soon support testing the cross compilation capabilities between 32/64
bit Windows, meaning that there's not "one true value" for any of these
environment variables that Cargo is setting (e.g. where to find `cl`, `link`,
etc). Instead, all dependencies have been updated to probe the system (in the
same manner as the compiler) for the tools that they're using.
All of the logic is housed in the `gcc` crate which now exposes a function to
probe the system for a particular tool. The updated crates here then use the
result of this probe to run the various build scripts. This all boils down to
being able to build MSVC targets inside an MSYS shell instead of requiring use
of a MSVC shell (which doesn't allow for simultaneous host builds and cross
builds).
I saw the usage of `call` locking up quite a bit when running this script on
Windows, and googling around on the internet seems to indicate that Popen should
be used instead of call to prevent this locking up, and it does indeed work!
It looks like the empty string is leaking in as a feature to all crates being
published on crates.io unintentionally. This means that each dependency edge
activates the feature `""`. This in turn confuses the resolution process quite a
bit, causing it to be far more recursive than it should be.
The empty feature, `""`, is weeded out during activation of features but it's
never explicitly activated. This means that each new dependency we see has one
requested feature (the empty one) with no activated features (as it doesn't have
any). This ends up causing us to recurse to attempt to reactivate the
dependency. This extreme recursion ended up blowing the stack on some smaller
crates and this commit fixes that.
It looks like the empty string is leaking in as a feature to all crates being
published on crates.io unintentionally. This means that each dependency edge
activates the feature `""`. This in turn confuses the resolution process quite a
bit, causing it to be far more recursive than it should be.
The empty feature, `""`, is weeded out during activation of features but it's
never explicitly activated. This means that each new dependency we see has one
requested feature (the empty one) with no activated features (as it doesn't have
any). This ends up causing us to recurse to attempt to reactivate the
dependency. This extreme recursion ended up blowing the stack on some smaller
crates and this commit fixes that.
When built from archive, downloaded from https://github.com/rust-lang/cargo/releases
version info looks like this: `cargo 0.3.0 ( ) (built 2015-05-16)`.
Patch will make it look like this: `cargo 0.3.0 (built 2015-05-16)`
Resolving a dependency graph may involve quite a bit of backtracking to select
different versions of crates, but the previous implementation of resolution
would not backtrack enough.
Once a dependency is completely resolved it's possible that any number of
candidates for its transitive dependencies were left out of the resolution
process (e.g. we didn't hit them yet). These candidates were not previously used
for backtracking (because resolution overall of the dependency finished), but
this commit alters the implementation to instead consider these as candidates
for backtracking.
Architecturally this changes the code to CPS to pass around a `finished`
continuation to allow tweaking the behavior whenever a dependency successfully
resolves. The key change is then that whenever a candidate for a dependency is
activated, we ensure the recursive step for the rest of the graph happens as a
sub-call. This means that if *anything* in the recursive call fails (including
some previous up-the-stack resolution) we'll retry the next candidate.
Closes#1800
Resolving a dependency graph may involve quite a bit of backtracking to select
different versions of crates, but the previous implementation of resolution
would not backtrack enough.
Once a dependency is completely resolved it's possible that any number of
candidates for its transitive dependencies were left out of the resolution
process (e.g. we didn't hit them yet). These candidates were not previously used
for backtracking (because resolution overall of the dependency finished), but
this commit alters the implementation to instead consider these as candidates
for backtracking.
Architecturally this changes the code to CPS to pass around a `finished`
continuation to allow tweaking the behavior whenever a dependency successfully
resolves. The key change is then that whenever a candidate for a dependency is
activated, we ensure the recursive step for the rest of the graph happens as a
sub-call. This means that if *anything* in the recursive call fails (including
some previous up-the-stack resolution) we'll retry the next candidate.
Closes#1800
Looks like the new LLVM version has optimizations which help out a good deal
with the recursion faced in the resolver, so let's use that version instead!
Development dependencies are traversed during the resolution process, causing
them to be returned as the list of dependencies for a package in terms of
resolution. The compilation phase would then filter these out depending on the
dependency's transitivity, but this was incorrectly accounted for when the
dependency showed up multiple times in a few lists.
This commit fixes this behavior by updating the filtering logic to ensure that
only activated optional dependencies (those whose feature names are listed) are
compiled.
Closes#1805
Development dependencies are traversed during the resolution process, causing
them to be returned as the list of dependencies for a package in terms of
resolution. The compilation phase would then filter these out depending on the
dependency's transitivity, but this was incorrectly accounted for when the
dependency showed up multiple times in a few lists.
This commit fixes this behavior by updating the filtering logic to ensure that
only activated optional dependencies (those whose feature names are listed) are
compiled.
Closes#1805
Dependencies aren't necessarily unique per name as the same dependency can show
up multiple times in various dependency kind lists, so it's not quite right to
use a hash map anyway.
This commit aims to have the end goal of adding AppVeyor CI support to this
repo, and along the way it ended up meaning that the dependency installation
bits were rewritten in Python. This has a number of benefits:
* Python is more portable than shell
* Python is more readable than shell
* curl is no longer required on Windows (powershell is used for downloads)
There are also a few minor updates made as part of this commit as well:
* The README has been updated in how to build Cargo
* We now use `sudo: false` on Travis for faster builds. This is done by
specifying packages to install instead of installing them ourselves.
* pkg-config is no longer listed as a required program
This commit aims to have the end goal of adding AppVeyor CI support to this
repo, and along the way it ended up meaning that the dependency installation
bits were rewritten in Python. This has a number of benefits:
* Python is more portable than shell
* Python is more readable than shell
* curl is no longer required on Windows (powershell is used for downloads)
There are also a few minor updates made as part of this commit as well:
* The README has been updated in how to build Cargo
* We now use `sudo: false` on Travis for faster builds. This is done by
specifying packages to install instead of installing them ourselves.
* pkg-config is no longer listed as a required program
Previously a Target was not considered to be in the key of the map to build
script dependencies, but this meant that information like whether it was a
dev-dependency was lost. As a result libraries would depend on the build scripts
of their dev-dependencies, causing an internal error when the build script
hadn't finished yet when the library was being built.
Closes#1751
