Auto merge of #4457 - behnam:book-pub, r=alexcrichton
[doc] Publish book to gh-pages
Export mdBook into `target/doc/book/`, to make it accessible at <http://doc.crates.io/book/>
I have tested the changes on my repo (but when I had this commit on top of the other PR) locally. The result is at <http://code.behnam.es/rust-cargo/book/>.
Auto merge of #4455 - behnam:book-enh, r=alexcrichton
[doc/book] Add introduction page and other enhancements
Preview: http://code.behnam.es/rust-cargo/book/
* Reorganize files to use folders instead of numbered files. This will allow us to add new sections and pages without breaking a numbering system or the URLs.
* Rename "Cargo In Depth" to "Cargo Reference", as those pages are considered *the* reference for cargo behaviors.
* Add `introduction.md`, as the landing page with the book title and Cargo logo on top.
* Expand `installation.md`: Import install text and links from <https://crates.io/install>, as we
want to drop that page and redirect it to here. (See <https://github.com/rust-lang/crates.io/issues/1029>)
* Sync `SUMMARY.md` titles (and sub-pages lists in section pages) with page titles and fix some wordings and casings.
* Expand Introduction and section pages with some intro text.
* Set lang for some of the code blocks.
* Add `book.toml` to get the title in HTML head title, etc.
bors [Thu, 31 Aug 2017 21:08:09 +0000 (21:08 +0000)]
Auto merge of #4453 - behnam:book, r=alexcrichton
Import mdBook-based docs and sync
Since we decided to keep the mdBook-based docs in-repo, I have imported the existing converted docs from <https://github.com/istankovic/cargo-book> under `/src/doc/book/` here, and have synced the current docs and the mdBook-based ones manually, file-by-file.
I have created a `MIGRATION_MAP` file, which shows the relationship between old docs and new ones. The first column is the old file, the second column is the canonical location in mdBook, and the rest of columns are globs of other files in mdBook containing content from the old file.
The first and second column of `MIGRATION_MAP` shall later be used to create redirect rules from `doc.crates.io/` to `doc.rust-lang.org/cargo/`.
I will also add a README file to remind everyone to keep these files in sync during the migration.
There are also two or three small wording fixes here, which I'll note inline.
This is a retry of <https://github.com/rust-lang/cargo/pull/4220>.
First step for <https://github.com/rust-lang/cargo/issues/4040>.
bors [Thu, 31 Aug 2017 20:26:56 +0000 (20:26 +0000)]
Auto merge of #4447 - lucaskolstad:proc-macro-crates-host-deps-linkage, r=alexcrichton
Add host dependency path via -L for cargo_test.
Proc-macro crates' dependencies in the host dependency directory cannot
be found when running `cargo test` with the `--target {target}` flag
set as reported in #4224. This adds the host dependency directory to the
search path to find those missing dependencies with -L when building tests
and adds a test case that fails before and passes after this patch.
A new function `find_host_deps(..)` is added to accomplish this which can
determine the path of the host dependencies directory from within
`run_doc_tests(..)` where the missing library search path is needed.
The test case seems to require a non-local crate from crates.io to example the failure before this patch. Couldn't make it fail with simply another local subcrate, but if others think it's possible that'd be great. This means that during tests for the cargo project itself that this test case actually downloads and compiles a crate, which I don't think any other tests do and is obviously not ideal and is perhaps even unacceptable. I've used the base64 crate pretty arbitrarily, but which crate it is really doesn't matter to test the case's content. So if anyone knows a tiny or empty crate on crates.io to use instead that'd speed this up and if someone can figure out how to make it fail before this patch is applied without downloading an external crate that would help as well.
Also, I'm not 100% confident about the `find_host_deps(..)` style and whether it's the best way to find the host dependencies directory with just the `TestOptions` and `Compilation` structs available since I'm new to this project. Any comments are appreciated.
Lucas Kolstad [Thu, 31 Aug 2017 17:55:19 +0000 (10:55 -0700)]
Tweak proc_macro test to correctly test case.
Minor change causes the test to actually test the case instead of always
passing regardless of the fix that adds the host dependency directory to
the library search path.
Lucas Kolstad [Thu, 31 Aug 2017 00:59:23 +0000 (17:59 -0700)]
Replace plugins_dylib_path with host_deps_output.
The plugins_dylib_path field on Compilation is removed because it is
identical to host_deps_output, it is only used in one easily replaced
location, and because host_deps_output is a more general name that
includes its new usage location in cargo_test.rs as well while better
matching the corresponding deps_output field.
Also de-indents erroneously indented lines in a test case.
Lucas Kolstad [Wed, 30 Aug 2017 22:16:52 +0000 (15:16 -0700)]
Remove find_host_deps and use Compilation field.
This patch removes the addition of the find_host_deps() function by
adding a host_deps_output field to the Compilation struct instead. The
test case is altered to not use an external crate from crates.io but
instead use the Package.publish(..) method.
Lucas Kolstad [Tue, 29 Aug 2017 10:43:41 +0000 (03:43 -0700)]
Add host dependency path via -L for cargo_test.
Proc-macro crates' dependencies in the host dependency directory cannot
be found when running `cargo test` with the `--target {target}` flag
set. This adds the host dependency directory with -L when building tests
and a test case that fails before and passes after this patch.
A new function find_host_deps(..) is added to accomplish this which can
determine the path of the host dependencies directory from within
run_doc_tests(..) where the missing library search path is needed.
bors [Mon, 28 Aug 2017 15:52:06 +0000 (15:52 +0000)]
Auto merge of #4442 - Xanewok:process-builder-program, r=alexcrichton
Allow to substitute executed program in `ProcessBuilder`
Extends #4424. Sorry for the noise, turns out it'd also be useful to substite the executed program (e.g. for rls, which needs to use a rustc shim itself) without having to copy over manually all parts of the `ProcessBuilder`.
While I'm at it, do you think this needs even more functionality, like being able to specify `None` for the `cwd` or `jobserver` (currently API exposes only ability to specify `Some(...)` as values for those)?
bors [Sun, 27 Aug 2017 15:39:13 +0000 (15:39 +0000)]
Auto merge of #4441 - vignesh-sankaran:manifest-doc-fix, r=alexcrichton
Replace maintenance status with ellipses
Since the default maintenance status isn't set to none if it isn't set, feel it'd be more appropriate to have ellipses instead like the other badge docs.
bors [Sat, 26 Aug 2017 17:57:40 +0000 (17:57 +0000)]
Auto merge of #4358 - Mark-Simulacrum:fix-cfg-cargo, r=alexcrichton
Discover crate type information late if necessary.
Some crates aren't found during eager crate-type searching due to being behind `cfg(...)` flags. We still want to be able to handle these, though, so when necessary we now call rustc again to get crate-type information for these cfg-ed crates.
This is necessary for https://github.com/rust-lang/rust/pull/41991.
Mark Simulacrum [Mon, 21 Aug 2017 11:46:31 +0000 (05:46 -0600)]
Discover crate type information late if necessary.
Some crates aren't found during eager crate-type searching due to being
behind `cfg(...)` flags. We still want to be able to handle these,
though, so when necessary we now call rustc again to get crate-type
information for these cfg-ed crates.
bors [Fri, 25 Aug 2017 16:02:02 +0000 (16:02 +0000)]
Auto merge of #4433 - alexcrichton:unstable-features, r=matklad
Add infrastructure for nightly features and flags
This PR starts adding infrastructure in Cargo for nightly features and nightly flags. The current design looks like:
* There's a new `package.cargo-features` manifest key which accepts an array of strings. This array of strings is the list of enabled Cargo features for that crate.
* A new suite of flags behind `-Z`, like the compiler, are accepted on the command line for all commands.
* Features and unstable flags in Cargo are required to be used on Cargo's nightly channel, which is the same as Rust's nightly channel.
* Features and unstable flags cannot be used on the stable/beta channels of Rust/Cargo.
* Crates which enable features in their manifest are disallowed from being published to crates.io
The motivation behind this support is unblock a number of efforts in Cargo by allowing them to safely get implemented behind a nightly feature gate. Once behind a feature gate they can iterate in-tree without having to worry about "insta stability" and we can also get valuable usage feedback about upstream users.
bors [Thu, 24 Aug 2017 13:56:50 +0000 (13:56 +0000)]
Auto merge of #4431 - vignesh-sankaran:maintenance-badge-docs, r=alexcrichton
Add maintenance badge docs
Pending merging of [this PR for crates.io](https://github.com/rust-lang/crates.io/pull/952). This should close off [#704 on crates.io](https://github.com/rust-lang/crates.io/issues/704). I've also updated the badge metadata docs and reordered the fields into groups by build, code coverage, and maintenance.
So I've decided to put the list of possible badge options in the documentation, we'll have to find another place to put more detailed descriptions of the available maintenance badges.
bors [Tue, 22 Aug 2017 15:26:56 +0000 (15:26 +0000)]
Auto merge of #4424 - Xanewok:process-builder-api, r=alexcrichton
Add `fn args_replace` and `fn get_program` to `ProcessBuilder`
`Executor::exec()` provides a `ProcessBuilder` argument representing compiler call and if someone wants to use it or modify it for their own purposes, they have to (partially) recreate it themselves.
This:
* makes the argument modification possible (via `args_replace`, analogous to `env_remove`)
* exposes the program that will be run (via `get_program`, in case `rustc` is overriden via wrapper etc.).
bors [Sun, 20 Aug 2017 18:35:22 +0000 (18:35 +0000)]
Auto merge of #4416 - Xanewok:more-executor-params, r=alexcrichton
Expose `Target` and `Unit` params to appropriate `Executor` callbacks
This effectively does only two things:
* Pass existing `&Unit` to `init()`
* Pass existing `&Target` to `exec()`s
Also updated doc comments slightly.
The `init()` is called for every `Work` preparation by `rustc()` and since it's not called once (not sure if intended?), it'd be good to include more information for which `Unit` the `rustc` process invocation has been initially prepared (I think more importantly it shows that `init()` is called many times for many targets).
Additionally, it'd be good to know about `Unit` compiled in the `exec()` callbacks in more structured manner (so the user doesn't have to parse the `ProcessBuilder` arguments and/or make certain assumptions) and since `target` was already cloned and moved into the closure, it was only a matter of exposing it.
I think it'd be ideal to provide all the necessary information to recreate a `Unit` but with a static lifetime needed for the closure, however this would mean cloning more data per-target ([`Kind`](https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_rustc/mod.rs#L41) should be basically free, however not sure if cloning [`Profile`](https://github.com/rust-lang/cargo/blob/master/src/cargo/core/manifest.rs#L151) is acceptable). With this, `Executor` users could query `Context` more easily (e.g. to get a unit dep graph! :smile:), as the API accepts `Unit`s in many places.
r? @alexcrichton
cc @nrc
EDIT:
This changes the public API, not sure if there's something else I should do about it, only ran `cargo test` locally.
bors [Sun, 20 Aug 2017 12:57:50 +0000 (12:57 +0000)]
Auto merge of #4364 - RalfJung:feat, r=alexcrichton
Required dependencies are not features
Also, while I was at it, I fixed an error message which complained about something not being an optional dependency, when really what mattered was that it was not a dependency at all.
I made a bunch of guesses about how things work. These guesses ended up as comments in the commit (so hopefully, the next reader of these files has to guess less). I am not totally certain these comments are all correct, so please yell if not. :)
In particular, for resolve_features, I observed that dependencies get compiled even when they are not returned from that function. But judging from how the function used to behave, it actually returns all dependencies, even those that have nothing to do with any features. (Making the name rather misleading, TBH...)
bors [Mon, 14 Aug 2017 23:23:05 +0000 (23:23 +0000)]
Auto merge of #4404 - parkovski:master, r=alexcrichton
Fix #4370 - init panic in C:\ or /
This fixes the crash in this issue, but the error message is strange - unable to create directory 'C:\\.'. I don't have write permissions there without becoming admin, so I suspect it's just a permission issue, but the weird error can be fixed by calling Path::canonicalize on line 300.
projects / cargo.git / log