Tracking issue for rustbuild, the alternate build system for rustc #31590
Comments
|
Also as the most bike-sheddy thing, I'm not a huge fan of the term "rustbuild", so I'd also be fine calling this something cooler like "rust laser build" |
|
This is a very simple thing, but I hit control-C while it was downloading stage0 and because the file wasn't valid, it just bailed out and I had to remove it manually. I'm not sure if deleting it and retrying is the right thing, or if this is just going to be a papercut generally. |
|
Sounds like a bug! (added a checkbox) |
|
By going from Please enable resuming on curl if possible, for people with narrowband. |
|
No, I would expect any build system to take dependencies into account. It's an implicit assumption of mine that any sort of dependency tracking done by the current build system must be done by rustbuild as well. |
|
Regarding the documentation features... maybe we should try to land rust-lang/cargo#2256 and then they could just be their own crates? |
|
I suspect that may not end up helping too much unfortunately, most of our docs are rustbook-based rather than rustdoc-based. |
|
Oh duh. I should, uh, know that 😅 The new book is going to use mdBook, and I think it should just be a drop-in replacement. Maybe it's time to kill rustbook for real? |
|
It probably doesn't matter either way in terms of dependency management and instrumentation of the compiler building mdbook/rustbook, so I suspect switching over wouldn't change things too much really |
|
@azerupi is okay with mdbook becoming a dependency https://github.com/azerupi/mdBook/issues/105#issuecomment-183518235 I will poke at that docs branch sometime next week. |
|
I'm going to look into building compiler-rt as a crate using cargo instead of having the bootstrap binary build it. This should get us closer to being able to (cross) compile the std crate with cargo, i.e. just |
|
(added some bullet points to that effect) |
alexcrichton
added
metabug
|
While trying to help out the AVR-Rust fork, I started using rustbuild. I've been able to compile LLVM, but then realized that I had to change the configuration of LLVM. I edited |
|
As a work-around, I've deleted all the |
|
@shepmaster ah yeah right now the build system doesn't track changes to itself. I personally found that to be the most annoying part of the makefiles and I was glad to not reimplement that, but I suspect we'll have to add that eventually. |
|
Also yeah, the handling of LLVM specifically may not be as great as it needs to be. Currently it unconditionally always configures via |
|
libc and alloc_system should be removed from liballoc's dependencies. With that change I can cross-compile a freestanding sysroot by depending on libcollections, https://github.com/AveryOS/avery/blob/master/sysroot/Cargo.toml |
|
Does this imply that any of the zillion crates under src are going to be split out onto Crates.io? |
|
@bstrie Not in the near future, since the old buikdsystem will still be around for a while. Once the Makefiles are gone, I expect that at least the crates that already have an official (owned by rust-lang or rust-lang-*) crates.io equivalent will be phased out in favor of of depending on the crates.io versions. |
This commit rewrites all of the tidy checks we have, namely: * featureck * errorck * tidy * binaries into Rust under a new `tidy` tool inside of the `src/tools` directory. This at the same time deletes all the corresponding Python tidy checks so we can be sure to only have one source of truth for all the tidy checks. cc rust-lang#31590
rustbuild: Migrate tidy checks to Rust This commit rewrites all of the tidy checks we have, namely: * featureck * errorck * tidy * binaries into Rust under a new `tidy` tool inside of the `src/tools` directory. This at the same time deletes all the corresponding Python tidy checks so we can be sure to only have one source of truth for all the tidy checks. cc #31590
This commit adds support to rustbuild to run crate unit tests (those defined by `#[test]`) as well as documentation tests. All tests are powered by `cargo test` under the hood. Each step requires the `libtest` library is built for that corresponding stage. Ideally the `test` crate would be a dev-dependency, but for now it's just easier to ensure that we sequence everything in the right order. Currently no filtering is implemented, so there's not actually a method of testing *only* libstd or *only* libcore, but rather entire swaths of crates are tested all at once. A few points of note here are: * The `coretest` and `collectionstest` crates are just listed as `[[test]]` entires for `cargo test` to naturally pick up. This mean that `cargo test -p core` actually runs all the tests for libcore. * Libraries that aren't tested all mention `test = false` in their `Cargo.toml` * Crates aren't currently allowed to have dev-dependencies due to rust-lang/cargo#860, but we can likely alleviate this restriction once workspaces are implemented. cc rust-lang#31590
… r=brson rustbuild: Add support for crate tests + doctests This commit adds support to rustbuild to run crate unit tests (those defined by `#[test]`) as well as documentation tests. All tests are powered by `cargo test` under the hood. Each step requires the `libtest` library is built for that corresponding stage. Ideally the `test` crate would be a dev-dependency, but for now it's just easier to ensure that we sequence everything in the right order. Currently no filtering is implemented, so there's not actually a method of testing *only* libstd or *only* libcore, but rather entire swaths of crates are tested all at once. A few points of note here are: * The `coretest` and `collectionstest` crates are just listed as `[[test]]` entires for `cargo test` to naturally pick up. This mean that `cargo test -p core` actually runs all the tests for libcore. * Libraries that aren't tested all mention `test = false` in their `Cargo.toml` * Crates aren't currently allowed to have dev-dependencies due to rust-lang/cargo#860, but we can likely alleviate this restriction once workspaces are implemented. cc rust-lang#31590
… r=brson rustbuild: Add support for crate tests + doctests This commit adds support to rustbuild to run crate unit tests (those defined by `#[test]`) as well as documentation tests. All tests are powered by `cargo test` under the hood. Each step requires the `libtest` library is built for that corresponding stage. Ideally the `test` crate would be a dev-dependency, but for now it's just easier to ensure that we sequence everything in the right order. Currently no filtering is implemented, so there's not actually a method of testing *only* libstd or *only* libcore, but rather entire swaths of crates are tested all at once. A few points of note here are: * The `coretest` and `collectionstest` crates are just listed as `[[test]]` entires for `cargo test` to naturally pick up. This mean that `cargo test -p core` actually runs all the tests for libcore. * Libraries that aren't tested all mention `test = false` in their `Cargo.toml` * Crates aren't currently allowed to have dev-dependencies due to rust-lang/cargo#860, but we can likely alleviate this restriction once workspaces are implemented. cc rust-lang#31590
rustbuild: Add support for crate tests + doctests This commit adds support to rustbuild to run crate unit tests (those defined by `#[test]`) as well as documentation tests. All tests are powered by `cargo test` under the hood. Each step requires the `libtest` library is built for that corresponding stage. Ideally the `test` crate would be a dev-dependency, but for now it's just easier to ensure that we sequence everything in the right order. Currently no filtering is implemented, so there's not actually a method of testing *only* libstd or *only* libcore, but rather entire swaths of crates are tested all at once. A few points of note here are: * The `coretest` and `collectionstest` crates are just listed as `[[test]]` entires for `cargo test` to naturally pick up. This mean that `cargo test -p core` actually runs all the tests for libcore. * Libraries that aren't tested all mention `test = false` in their `Cargo.toml` * Crates aren't currently allowed to have dev-dependencies due to rust-lang/cargo#860, but we can likely alleviate this restriction once workspaces are implemented. cc #31590
|
Ok, almost all work is now done on this metabug, and I believe that rustbuild is now at feature parity with respect to the set of the makefiles that we run on all our automation (dist bots, auto bots, etc). As a result I'm going to close this out as it's all "basically done" (yay!). There's a number of issues still tagged A-rustbuild, and we can use that label for tracking issues with rustbuild moving forward. |
I'm opening this up as a tracking issue for all work that needs to happen to get rustbuild, our new build system, turned on by default. The end goal here is to completely jettison our thousands of lines of makefiles and configure scripts for tons and tons of Rust code! Initial support has landed in #31123, but we've still got quite aways to go!
Here's a list of items left that need to be implemented, and help is always appreciated when tackling these! If you want any clarifications or any help on any of these, feel free to reach out to me (acrichto) on IRC.
Documentation
work in progress
Testing
Porting
These should all be verified to work and then ideally we'd add a builder verifying they continue to work!
configurescriptMisc
--enable-rustbuild, but not run tests - Add auto builders for rustbuild build system rust-lang-deprecated/rust-buildbot#61make clean- Addmake cleansupport to rustbuild #31591make install+make distThese are pretty huge portions of the make files, they may take quite some time to migrate over, and it's probably fine to keep them around for now. @brson's plans with
multirust-rsand reusable library components may become relevant here as well.This may be subdivided into a bunch of smaller tasks over time!
make dist- rustbuild: Implementmake dist#32237Far future (not required)
src/bootstrap/bootstrap.pybeing called directly (e.g. on MSVC wheremakeisn't available)rustcfor architectures that can themselves not be run. For example a x86_64 host should be able to build an arm compiler (e.g. a full installation tarball) - Enable bootstrapping non-build-machine targets #31884The text was updated successfully, but these errors were encountered: