development/cargo
development/cargo
1
0
Fork 0
mirror of https://github.com/rust-lang/cargo synced 2024-09-18 07:12:12 +00:00
Code Issues Packages Projects Releases Wiki Activity
cargo/Cargo.toml

63 lines
1.1 KiB
TOML
Raw Normal View History

Bootstrap cargo with cargo
2014-07-16 00:51:49 +00:00
[project]
name = "cargo"
Bump to 0.10.0
2016-03-03 19:12:10 +00:00
version = "0.10.0"
Bootstrap cargo with cargo
2014-07-16 00:51:49 +00:00
authors = ["Yehuda Katz <wycats@gmail.com>",
Add Alex to the authors.
2014-11-13 23:08:17 +00:00
"Carl Lerche <me@carllerche.com>",
"Alex Crichton <alex@alexcrichton.com>"]
Tweak metadata to publish Cargo on crates.io 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`
2015-07-24 21:37:03 +00:00
license = "MIT/Apache-2.0"
homepage = "https://crates.io"
repository = "https://github.com/rust-lang/cargo"
Update documentation link for API docs The API docs for Cargo live at doc.crates.io/cargo, not doc.crates.io in general.
2016-03-03 21:09:52 +00:00
documentation = "http://doc.crates.io/cargo"
Tweak metadata to publish Cargo on crates.io 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`
2015-07-24 21:37:03 +00:00
description = """
Cargo, a package manager for Rust.
"""
Bootstrap cargo with cargo
2014-07-16 00:51:49 +00:00
Register new snapshots
2014-08-16 20:00:46 +00:00
[lib]
Bootstrap cargo with cargo
2014-07-16 00:51:49 +00:00
name = "cargo"
path = "src/cargo/lib.rs"
Move all deps to the registry
2014-12-19 03:01:37 +00:00
[dependencies]
Fix build on MSVC * Download all snapshots and such from static.rust-lang.org (drive-by fix) * Update dependencies to work and build on MSVC * ssh2-sys uses `nmake` to build libssh2 * libgit2-sys uses `cmake` to build libgit2 * curl-sys uses `nmake` to build libcurl * libz-sys uses `nmake` to build zlib * miniz-sys uses `gcc-rs` to drive `cl.exe` manually * term updated to pick up windows-specific deps on MSVC * Updated .travis.install.deps.sh to install MSVC target libraries on Windows, so the compiler can be used to target MSVC. A 64-bit target is now used by default as well. * Updated the configure script and Makefile to set appropriate environment variables to build Cargo from a MSYS shell with a MSVC target. This is similar to how Rust bootstraps on MSVC as well. With this commit Cargo can successfully bootstrap itself on MSVC (use the MSVC product to build itself again). The tests currently do not pass because unwinding is not implemented, but soon!
2015-06-15 05:13:08 +00:00
advapi32-sys = "0.1"
Bump the crates-io crate to 0.2
2016-04-14 17:04:23 +00:00
crates-io = { path = "src/crates-io", version = "0.2" }
Update dependencies and Rust version Just a routine for niche bug fixes, linkage errors, perf improvements, etc.
2016-01-20 17:07:47 +00:00
crossbeam = "0.2"
Loosen the dependency versions in Cargo.toml
2015-04-26 21:42:55 +00:00
curl = "0.2"
docopt = "0.6"
Update to rust 2015-03-26
2015-03-26 18:17:44 +00:00
env_logger = "0.3"
Fix build on MSVC * Download all snapshots and such from static.rust-lang.org (drive-by fix) * Update dependencies to work and build on MSVC * ssh2-sys uses `nmake` to build libssh2 * libgit2-sys uses `cmake` to build libgit2 * curl-sys uses `nmake` to build libcurl * libz-sys uses `nmake` to build zlib * miniz-sys uses `gcc-rs` to drive `cl.exe` manually * term updated to pick up windows-specific deps on MSVC * Updated .travis.install.deps.sh to install MSVC target libraries on Windows, so the compiler can be used to target MSVC. A 64-bit target is now used by default as well. * Updated the configure script and Makefile to set appropriate environment variables to build Cargo from a MSYS shell with a MSVC target. This is similar to how Rust bootstraps on MSVC as well. With this commit Cargo can successfully bootstrap itself on MSVC (use the MSVC product to build itself again). The tests currently do not pass because unwinding is not implemented, but soon!
2015-06-15 05:13:08 +00:00
filetime = "0.1"
Loosen the dependency versions in Cargo.toml
2015-04-26 21:42:55 +00:00
flate2 = "0.2"
Fix running Cargo concurrently Cargo has historically had no protections against running it concurrently. This is pretty unfortunate, however, as it essentially just means that you can only run one instance of Cargo at a time **globally on a system**. An "easy solution" to this would be the use of file locks, except they need to be applied judiciously. It'd be a pretty bad experience to just lock the entire system globally for Cargo (although it would work), but otherwise Cargo must be principled how it accesses the filesystem to ensure that locks are properly held. This commit intends to solve all of these problems. A new utility module is added to cargo, `util::flock`, which contains two types: * `FileLock` - a locked version of a `File`. This RAII guard will unlock the lock on `Drop` and I/O can be performed through this object. The actual underlying `Path` can be read from this object as well. * `Filesystem` - an unlocked representation of a `Path`. There is no "safe" method to access the underlying path without locking a file on the filesystem first. Built on the [fs2] library, these locks use the `flock` system call on Unix and `LockFileEx` on Windows. Although file locking on Unix is [documented as not so great][unix-bad], but largely only because of NFS, these are just advisory, and there's no byte-range locking. These issues don't necessarily plague Cargo, however, so we should try to leverage them. On both Windows and Unix the file locks are released when the underlying OS handle is closed, which means that if the process dies the locks are released. Cargo has a number of global resources which it now needs to lock, and the strategy is done in a fairly straightforward way: * Each registry's index contains one lock (a dotfile in the index). Updating the index requires a read/write lock while reading the index requires a shared lock. This should allow each process to ensure a registry update happens while not blocking out others for an unnecessarily long time. Additionally any number of processes can read the index. * When downloading crates, each downloaded crate is individually locked. A lock for the downloaded crate implies a lock on the output directory as well. Because downloaded crates are immutable, once the downloaded directory exists the lock is no longer needed as it won't be modified, so it can be released. This granularity of locking allows multiple Cargo instances to download dependencies in parallel. * Git repositories have separate locks for the database and for the project checkout. The datbase and checkout are locked for read/write access when an update is performed, and the lock of the checkout is held for the entire lifetime of the git source. This is done to ensure that any other Cargo processes must wait while we use the git repository. Unfortunately there's just not that much parallelism here. * Binaries managed by `cargo install` are locked by the local metadata file that Cargo manages. This is relatively straightforward. * The actual artifact output directory is just globally locked for the entire build. It's hypothesized that running Cargo concurrently in *one directory* is less of a feature needed rather than running multiple instances of Cargo globally (for now at least). It would be possible to have finer grained locking here, but that can likely be deferred to a future PR. So with all of this infrastructure in place, Cargo is now ready to grab some locks and ensure that you can call it concurrently anywhere at any time and everything always works out as one might expect. One interesting question, however, is what does Cargo do on contention? On one hand Cargo could immediately abort, but this would lead to a pretty poor UI as any Cargo process on the system could kick out any other. Instead this PR takes a more nuanced approach. * First, all locks are attempted to be acquired (a "try lock"). If this succeeds, we're done. * Next, Cargo prints a message to the console that it's going to block waiting for a lock. This is done because it's indeterminate how long Cargo will wait for the lock to become available, and most long-lasting operations in Cargo have a message printed for them. * Finally, a blocking acquisition of the lock is issued and we wait for it to become available. So all in all this should help Cargo fix any future concurrency bugs with file locking in a principled fashion while also allowing concurrent Cargo processes to proceed reasonably across the system. [fs2]: https://github.com/danburkert/fs2-rs [unix-bad]: http://0pointer.de/blog/projects/locking.html Closes #354
2016-03-12 17:58:53 +00:00
fs2 = "0.2"
Update dependency on git2 This crate was recently updated to the next release of libgit2, and I've noticed historically that a noop `cargo build` was slow in the git2-rs repository. Curious to see if the new libgit2 version helped speed things up at all, I tested it out. Before this commit, a noop `cargo build` produced 599108 syscalls. After this commit, a noop build produced 86925 syscalls, an 85% reduction in the number of syscalls! Needless to say it's much faster.
2016-02-26 21:47:56 +00:00
git2 = "0.4"
git2-curl = "0.4"
Loosen the dependency versions in Cargo.toml
2015-04-26 21:42:55 +00:00
glob = "0.2"
Update dependencies and Rust version Just a routine for niche bug fixes, linkage errors, perf improvements, etc.
2016-01-20 17:07:47 +00:00
kernel32-sys = "0.2"
Bump libc to 0.2 Also update everything else which removes all remaining libc 0.1 dependencies
2015-12-20 22:58:55 +00:00
libc = "0.2"
Update dependency on git2 This crate was recently updated to the next release of libgit2, and I've noticed historically that a noop `cargo build` was slow in the git2-rs repository. Curious to see if the new libgit2 version helped speed things up at all, I tested it out. Before this commit, a noop `cargo build` produced 599108 syscalls. After this commit, a noop build produced 86925 syscalls, an 85% reduction in the number of syscalls! Needless to say it's much faster.
2016-02-26 21:47:56 +00:00
libgit2-sys = "0.4"
Loosen the dependency versions in Cargo.toml
2015-04-26 21:42:55 +00:00
log = "0.3"
Fix build on MSVC * Download all snapshots and such from static.rust-lang.org (drive-by fix) * Update dependencies to work and build on MSVC * ssh2-sys uses `nmake` to build libssh2 * libgit2-sys uses `cmake` to build libgit2 * curl-sys uses `nmake` to build libcurl * libz-sys uses `nmake` to build zlib * miniz-sys uses `gcc-rs` to drive `cl.exe` manually * term updated to pick up windows-specific deps on MSVC * Updated .travis.install.deps.sh to install MSVC target libraries on Windows, so the compiler can be used to target MSVC. A 64-bit target is now used by default as well. * Updated the configure script and Makefile to set appropriate environment variables to build Cargo from a MSYS shell with a MSVC target. This is similar to how Rust bootstraps on MSVC as well. With this commit Cargo can successfully bootstrap itself on MSVC (use the MSVC product to build itself again). The tests currently do not pass because unwinding is not implemented, but soon!
2015-06-15 05:13:08 +00:00
num_cpus = "0.2"
Loosen the dependency versions in Cargo.toml
2015-04-26 21:42:55 +00:00
regex = "0.1"
rustc-serialize = "0.3"
Bump semver version Fixes #2337
2016-02-01 20:12:17 +00:00
semver = "0.2.2"
Update dependencies and Rust version Just a routine for niche bug fixes, linkage errors, perf improvements, etc.
2016-01-20 17:07:47 +00:00
tar = "0.4"
Detect whether or not the terminal supports color. Before v0.4, term used to return `Ok(true)` if something succeeded, `Ok(false)` if the operation was unsupported, and `Err(io::Error)` if there was an IO error. Now, it returns `Ok(())` if the operation succeeds and `Err(term::Error)` if the operation fails. If the operation is unsupported, it returns `Err(term::Error::NotSupported)`. This means that, if `op` is unsupported, `try!(term.op())` will now return an error instead of silently failing (well, return false but that's effectively silent). Fixes #2338
2016-02-01 01:03:14 +00:00
term = "0.4.4"
Loosen the dependency versions in Cargo.toml
2015-04-26 21:42:55 +00:00
time = "0.1"
toml = "0.1"
url = "0.2"
Remove MSVC logic from the configure script 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).
2015-07-22 21:38:35 +00:00
winapi = "0.2"
Use external crates for Windows FFI Signed-off-by: Peter Atashian <retep998@gmail.com>
2015-01-20 16:01:52 +00:00
Fix all tests from the update to rust master
2015-03-09 19:07:35 +00:00
[dev-dependencies]
tempdir = "0.3"
Tweak metadata to publish Cargo on crates.io 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`
2015-07-24 21:37:03 +00:00
hamcrest = "0.1"
Update Cargo to rust master There was a lifetime parameter regression in git2-rs which prevented Cargo from building on nightly
2015-05-13 04:22:14 +00:00
bufstream = "0.1"
Move Cargo onto stable Rust This commit moves Cargo onto 100% stable Rust now that the necessary fs features have been stabilized. The tests were updated to understand when they're running with a non-nightly compiler and disable all plugin-related tests. The only major feature here is that the calls to `fs::set_file_times` were reimplemented manually in the tests that Cargo has. Cargo still requires a *nightly compiler* due to the stable features not having made their way into the stable channel yet, but it will soon work on all of the stable, beta, and nightly compilers once 1.1 is released!
2015-06-13 00:37:19 +00:00
filetime = "0.1"
Update how cargo talks to the registry This commit includes a laundry list of updates and tweaks to reflect the current API of the registry: * `registry.host` has been renamed to `registry.index` * New top-level manifest keys are now accepted: * `homepage` - url * `documentation` - url * `repository` - url * `description` - a markdown-less blurb * `license` - string (verified by the registry on upload) * `keywords` - string array * `readme` - string pointing at a file * Authors are now uploaded to the registry * The upload format to the registry has changed to a body json payload * Unpacking tarballs respects the executable bit for scripts and such. * Downloading now follows redirects to go to S3. * The download URL for a package has changed slightly. * Verify path dependencies have a version listed when being uploaded * Rename `upload` to `publish` * Rename `ops::cargo_upload` to `ops::registry` * Add a new `registry` package for interoperating with the registry * Add the ability to modify owners via `cargo owner` * Add a `readme` key to the manifest, and upload its contents to the registry. * Add the ability to yank crates and their versions * When packaging a library, verify that it builds from the packaged source by unpacking the tarball and simulate running `cargo build` inside of it.
2014-09-27 04:14:46 +00:00
Bootstrap cargo with cargo
2014-07-16 00:51:49 +00:00
[[bin]]
name = "cargo"
test = false
Remove docs that shouldn't be built
2014-08-14 21:54:56 +00:00
doc = false
Bootstrap cargo with cargo
2014-07-16 00:51:49 +00:00
[[test]]
name = "tests"
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.
2014-10-17 15:17:17 +00:00
[[test]]
name = "resolve"
Reference in a new issue Copy permalink