These are very basic commands for invoking Servo underneath rr. rr
currently doesn't support all the syscalls that Servo requires, but
that's easy to fix on the rr side.
Fixes#4177.
This avoids changing any directories outside the repo, which is better for
some automation scenarios.
The servobuild.example file has a "cache-dir" setting that restores the
previous default location of `~/.servo`, which is useful for developers
working with multiple clones on the same machine.
The majority of this change is simply re-arranging the code in the glutin port
so that the windowed/headless code is configured at build time rather
than runtime. There shouldn't be any functional difference as a result of this change.
This is a quick and dirty workaround for issue #3928. Basically, `cargo test` is deleting `./target/servo`, which is clearly not ideal if we want to do anything with servo after running the unit tests. This PR makes sure to rebuild after running `./mach test-unit`.
I'm not familiar enough with cargo yet to know why it's doing this or what better alternatives there are to fixing this. Having to rebuild afterwards feels pretty ugly to me, but my rationalization right now is that the time it takes to build is negligible in comparison to the time it takes to run the tests. Ideally, this should be something we could take care of in Cargo.toml, but again, I'm new to this (and the documentation seems less than helpful from what I can tell so far).
I won't be available for the rest of the day, so if anyone has suggestions, or wants to wait for a better solution, I'll get back to it tomorrow probably. Otherwise, this PR at least makes `./mach test` work properly, so there's that.
Bootstrapping automatically downloads new Rust and Cargo snapshots
as needed into versioned directories,
but do not remove now-unused versions.
This is the desired behavior for `git bisect` to be usable.
However, this means that old version keep accumulating, taking up disk space.
This adds a mach command to remove snapshots other than the ones
currently being used.
It is never run automatically.
To be safe, the command defaults to only printing what would be removed,
and only removes stuff when run with a `-f` argument.
Since default argument to params is None, concatenating it with a
list will raise an error. This behaviour prevents `./mach rustc`
to be called when system-rust is defined in .servobuild.
Currently it will only work when followed by an argument, i.e.
`./mach rustc -arg`.
Testing this patch: `./mach rustc` should not raise an error.
Since default argument to params is None, concatenating it with a
list will raise an error. This behaviour prevents `./mach rustc`
to be called when system-rust is defined in .servobuild.
Currently it will only work when followed by an argument, i.e.
`./mach rustc -arg`.
Testing this patch: `./mach rustc` should not raise an error.
When running commands through Registrar.dispatch, mach does not behave
in the same way it would as if it were running through the command line.
Defaults normally provided through a combination of @CommandArgument and
argparse magic are ignored.
I have some ideas as to how to fix this, but until then, this will allow
`./mach test` to run through test-unit properly.
