Compile tests for multiple packages#1828
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
8b8df3e to
64a8cb0
Compare
There was a problem hiding this comment.
cc @BurntSushi, you mentioned on docopt/docopt#275 that you were thinking of proposing the ability to do this in the options section instead of up here in the usage section, do you know if there's been progress on that? I wouldn't mind proposing an idea or two on that thread to see if I can get discussion rolling again, it'd be great to fix :)
There was a problem hiding this comment.
@alexcrichton Thanks for the reminder! I have a candidate implementation working in 0.6.69. See my proposal for details: docopt/docopt#275 (Even though it's working in the Rust implementation, I probably wouldn't add it into Cargo quite yet in case the proposal changes. If it's ultimately rejected, I might still leave it in because I think it's really really useful.)
|
Yeah this all looks like a pretty good approach to me! |
64a8cb0 to
44957f6
Compare
a56fd80 to
38335d8
Compare
|
☔ The latest upstream changes (presumably #1830) made this pull request unmergeable. Please resolve the merge conflicts. |
35c6833 to
4f7f409
Compare
|
I finally had time to work on this PR again. I have started adding tests, but I am not sure how to test |
|
☔ The latest upstream changes (presumably #1973) made this pull request unmergeable. Please resolve the merge conflicts. |
|
The nondeterminism may be solved by |
There was a problem hiding this comment.
I think that new syntax in docopt may actually allow for nicer definitions of this, something like:
Options:
-p, --package=SPEC ... Description ...
I believe it's still somewhat experimental, but this may be a good place to get a good start on it?
2ebf892 to
016e971
Compare
|
I've squashed the commits down to 6, but I could reduce the number even further if necessary. |
016e971 to
d9615d7
Compare
|
Looks like this may have accidentally picked up some other commits, perhaps a rebase is in order? I'll give this one last look-through but I'll probably just send it to bors. |
This PR for #1528 is still pretty rough (and so far only added multiple package support for tests), but I wanted to make sure the overall approach is fine. I have made some progress and cargo is now able to compile and execute tests for multiple packages. In order to execute the doc tests for multiple packages as well, I added `to_doc_test` to `Compilation` (used [here](fhahn@8b8df3e#diff-417e085367d0ce027505dfaa26a089d3R33)). Previously it only executed the doc tests for `Compilation.package`. Another option would be to change `Compilation.package` to be a `Vec<Package>`, because in order to execute the tests of multiple packages, multiple packages are compiled as "top level package". But this would require a changes at a couple of other places.
|
☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
|
Great, thanks @alexcrichton for your patience :) |
Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124.
Run all unit tests with just one Cargo command. Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7813) <!-- Reviewable:end -->
Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124.
Run all unit tests with just one Cargo command. Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7813) <!-- Reviewable:end -->
Run all unit tests with just one Cargo command. Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7813) <!-- Reviewable:end -->
…from servo:parallel-unit-tests); r=mbrubeck Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124. Source-Repo: https://github.com/servo/servo Source-Revision: ba2714f4f607da77bd7200f88cfa16c1d10da9cd
Allow `cargo doc --open` with multiple packages. If `cargo doc --open` builds multiple packages, open the first one. This seems pretty natural to me (the first one on the command line, or the first default member if `default-members` is specified, or the root of a workspace). Rustdoc shows a list of crates in the sidebar, so if it doesn't open the one the user wants, it's a trivial matter of clicking on the crate name. @alexcrichton specifically asked for an error [here](#1828 (diff)). However, at the time I don't think rustdoc dynamically generated the "Crates" listing in the sidebar. Alex, I wonder if your stance still holds? Closes #5145
…from servo:parallel-unit-tests); r=mbrubeck Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124. Source-Repo: https://github.com/servo/servo Source-Revision: ba2714f4f607da77bd7200f88cfa16c1d10da9cd UltraBlame original commit: a747ff057fac88586b57a543cf00052e24c93afe
…from servo:parallel-unit-tests); r=mbrubeck Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124. Source-Repo: https://github.com/servo/servo Source-Revision: ba2714f4f607da77bd7200f88cfa16c1d10da9cd UltraBlame original commit: a747ff057fac88586b57a543cf00052e24c93afe
…from servo:parallel-unit-tests); r=mbrubeck Upgrade Cargo to get rust-lang/cargo#1828, and use it for unit tests. This allows Cargo to get some more parallelism when compiling the test crates’ dependencies. `touch components/util/lib.rs && mach test-unit` on my machine goes from 149 seconds to 124. Source-Repo: https://github.com/servo/servo Source-Revision: ba2714f4f607da77bd7200f88cfa16c1d10da9cd UltraBlame original commit: a747ff057fac88586b57a543cf00052e24c93afe
This PR for #1528 is still pretty rough (and so far only added multiple package support for tests), but I wanted to make sure the overall approach is fine.
I have made some progress and cargo is now able to compile and execute tests for multiple packages.
In order to execute the doc tests for multiple packages as well, I added
to_doc_testtoCompilation(used here). Previously it only executed the doc tests forCompilation.package. Another option would be to changeCompilation.packageto be aVec<Package>, because in order to execute the tests of multiple packages, multiple packages are compiled as "top level package". But this would require a changes at a couple of other places.