rustbuild: Rewrite user-facing interface #37521
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
alexcrichton
force-pushed
the
new-rustbuild
branch
from
3992c7e
to
30bcc1c
Compare
|
|
||
| ./x.py build src/libcore | ||
| ./x.py build src/libproc_macro | ||
| ./x.py build src/libstd --stage 1 --filter hash_map |
There was a problem hiding this comment.
Ah this is actually a way to pass extra arguments to the test harness itself (e.g. the executable). In most cases that ends up being a filter, but not always in the case of things like -q or such.
I'll change the name of this to --test-args
There was a problem hiding this comment.
The rename is good if it's really just arbitrary arguments to the test runner. But there's another confusing thing here: The example invokes build, not test. Does this ``build` command include testing or is that a typo?
There was a problem hiding this comment.
Oops the --filter here was totally off, moved it elsewhere
|
Seems good, but I'll mostly take your word for it that it's correct. I see rules are defined by a name and a path. Does that mean I can use either to invoke them? e.g. how do I run tidy? Is it reasonable to have a command that lists all the rules? |
|
@brson the name of each rule is actually just a human readable string for defining rules itself. There's not necessarily a path for all rules so the path can't be the unique key. I figured it was just best to define everything in one place instead of scattered across a few. And yeah so to run tidy you'd do: I do think it's reasonable yeah to print out all options, I'll look for a location to put that. |
|
@alexcrichton Also, could you answer the questions in https://internals.rust-lang.org/t/the-rustbuild-feature-thread/3643/19 for the updated interface? |
alexcrichton
force-pushed
the
new-rustbuild
branch
from
30bcc1c
to
1d246aa
Compare
|
@brson ok, updated! In rustbuild there's no need for Otherwise the equivalences are:
And sure! Once we've landed this I can respond to that thread. |
alexcrichton
force-pushed
the
new-rustbuild
branch
from
1d246aa
to
d760453
Compare
|
@alexcrichton
All is usually too much if you're doing some other work on the same machine, that's why I usually use a fixed number. |
|
@bors r+ |
|
📌 Commit d760453 has been approved by |
|
I suggest posting to irlo about this when it lands since it changes the entire interface. |
|
Is |
|
@japaric that invocation would now look like: That is, you want to create a stage1 host compiler which has the stage1 libstd library, all for the target arm-unknown-linux-gnueabi. The |
Yes, that's what I meant. Will this produce a "proper" sysroot that's usable with
Oh, that's nifty. I think there wasn't a command for that before. If there was, I have no idea what it was. 😄 |
|
Ah yes so the method of multiple targets and specifying what to build was also updated to be "more correct" as part of this rewrite. That is, let's say you configured with one host of ARM and one target of powerpc. This means that x86_64 is the build triple, ARM and x86_64 are the host triples, and then there's three target triples. The various possibilities for building things are: I haven't personally used At least, if it doesn't do that, then that's a bug! |
|
☔ The latest upstream changes (presumably #37540) made this pull request unmergeable. Please resolve the merge conflicts. |
This commit is a rewrite of the user-facing interface to the rustbuild build
system. The intention here is to make it much easier to compile/test the project
without having to remember weird rule names and such. An overall view of the new
interface is:
# build everything
./x.py build
# document everyting
./x.py doc
# test everything
./x.py test
# test libstd
./x.py test src/libstd
# build libcore stage0
./x.py build src/libcore --stage 0
# run stage1 run-pass tests
./x.py test src/test/run-pass --stage 1
The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py`
script. This `x` was chosen to be both short and easily tab-completable (no
collisions in that namespace!). The build system now accepts a "subcommand" of
what to do next, the main ones being build/doc/test.
Each subcommand then receives an optional list of arguments. These arguments are
paths in the source repo of what to work with. That is, if you want to test a
directory, you just pass that directory as an argument.
The purpose of this rewrite is to do away with all of the arcane renames like
"rpass" is the "run-pass" suite, "cfail" is the "compile-fail" suite, etc. By
simply working with directories and files it's much more intuitive of how to run
a test (just pass it as an argument).
The rustbuild step/dependency management was also rewritten along the way to
make this easy to work with and define, but that's largely just a refactoring of
what was there before.
The *intention* is that this support is extended for arbitrary files (e.g.
`src/test/run-pass/my-test-case.rs`), but that isn't quite implemented just yet.
Instead directories work for now but we can follow up with stricter path
filtering logic to plumb through all the arguments.
alexcrichton
force-pushed
the
new-rustbuild
branch
from
d760453
to
a270b80
Compare
|
@bors: r=brson |
|
📌 Commit a270b80 has been approved by |
|
⌛ Testing commit a270b80 with merge f3c8663... |
|
💔 Test failed - auto-mac-64-opt-rustbuild |
|
@bors: retry |
|
⌛ Testing commit a270b80 with merge 9374d2c... |
|
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
This commit is a rewrite of the user-facing interface to the rustbuild build
system. The intention here is to make it much easier to compile/test the project
without having to remember weird rule names and such. An overall view of the new
interface is:
The
src/bootstrap/bootstrap.pyscript is now aliased as a top-levelx.pyscript. This
xwas chosen to be both short and easily tab-completable (nocollisions in that namespace!). The build system now accepts a "subcommand" of
what to do next, the main ones being build/doc/test.
Each subcommand then receives an optional list of arguments. These arguments are
paths in the source repo of what to work with. That is, if you want to test a
directory, you just pass that directory as an argument.
The purpose of this rewrite is to do away with all of the arcane renames like
"rpass" is the "run-pass" suite, "cfail" is the "compile-fail" suite, etc. By
simply working with directories and files it's much more intuitive of how to run
a test (just pass it as an argument).
The rustbuild step/dependency management was also rewritten along the way to
make this easy to work with and define, but that's largely just a refactoring of
what was there before.
The intention is that this support is extended for arbitrary files (e.g.
src/test/run-pass/my-test-case.rs), but that isn't quite implemented just yet.Instead directories work for now but we can follow up with stricter path
filtering logic to plumb through all the arguments.