Allow `./mach build` to enable Servo's headless mode
As mentioned in #7512 and #7637, the environment variable SERVO_HEADLESS
enables building the OSMesa version of Servo when it is set to 1.
Instead, this should be a command line option to mach's build command.
Fixes#7637.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7734)
<!-- Reviewable:end -->
As mentioned in #7512 and #7637, the environment variable SERVO_HEADLESS
enables building the OSMesa version of Servo when it is set to 1.
Instead, this should be a command line option to mach's build command.
Fixes#7637.
Urg! The Chromium HSTS preload JSON file contains single line comments. Previously these were filtered out with a very simple regex that just looked for '//' and removed the line. Now the file has added a couple fields that have URLs in them that were erroneously removed and caused the JSON parsing to fail. This commit slightly complicates the regex to fix this specific problem.
If this happens again, it's likely worth it to figure out how to use a real parser to remove the comments.
servo/servo#8760
Form relative reference URLs during create-wpt
Instead of always using the absolute path to the reference file when
creating new reference tests, create-wpt now creates relative URLs if
the files are in the same directory. This is the most common case for
new Servo tests. Also fix some missing quotation marks in the
create-wpt template.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8415)
<!-- Reviewable:end -->
Instead of always using the absolute path to the reference file when
creating new reference tests, create-wpt now creates relative URLs if
the files are in the same directory. This is the most common case for
new Servo tests. Also fix some missing quotation marks in the
create-wpt template.
Add CCACHE infra and turn it on in travis
r? @Manishearth
This lets devs configure their use of CCACHE with their .servobuild file, as usual. For build environments, they can either have a .servobuild file or set the CCACHE env var to point at the ccache binary to use.
It also adds support for ccache to our travis builds. Buildbot will come in a separate commit to the saltfs repo.
It is expected that the various cargo makefiles will look at this variable and do the "right thing" to tell their native build to instead use ccache. e.g., https://github.com/servo/mozjs/pull/62
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8366)
<!-- Reviewable:end -->
When mach_bootstrap got interrupted while it's setting up virtualenv or
calling out to pip, it wouldn't repeat that step on subsequent runs, and
mach fails because its environment isn't set up properly or dependencies
are missing.
So now we re-run virtualenv if activate_this.py doesn't exist, and only
create the marker file for required packages after pip has returned
successfully.
New Android suppport
r/f? @mbrubeck
No need to r+ urgently; I want to do a little bit more testing of the release build, but I'm hoping to land this bit (moving to a more sane build process) next week.
The new version of building an APK:
1) Removes the glutin-based APK builder from the link step
2) Adds a build.rs step to the build of the final Servo library that adds the native code required by glutin's android_rs_glue (e.g., `ANativeActivity_onCreate` definition)
3) Replaces the link step with a `fake-ld.sh` script that instead creates a libservo.so
4) Adds a new mach `package` step to build the APK that has some Rust code that builds the library from a set of in-tree build files
This setup fixes a number of problems:
1) We can use gdb, because we use `ndk-build`, which adds the .gdbserver info, plus we keep around all of the build files (also required by the ndk gdb)
2) We can add more Java code & hooks to handle Android intents
3) We no longer have any git submodules or the awkward two-step build with android-rs-glue
Many other setups were tried (and failed). The most obvious ones is building a libservo.so from a `dylib` target from the servo build on Android. This doesn't work because you can't have a different default lib target on one platform than others in Cargo, and you also can't pass it in from the commandline (e.g., --lib does not have a dylib arg). Additionally, if you don't go through the intermediate libservo.rlib step (which removes unused symbols), then you end up with a TON of missing symbols because our -sys crates are super sloppy about that. I spent a few weeks beginning to clean them up, but since it's something we can't easily enforce (and new -sys packages will have this problem, too, since it's only an issue with the Android loader), it made more sense to me to just have the build set up to discard those unused bits of code before they ever get to the linker, much less the loader.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8288)
<!-- Reviewable:end -->
Continuous non-transient notifications, common in workflows involving
many syntax errors, can completely take over the message tray. Making
Linux build notifications transient prevents them from stacking up in
Gnome Shell without having to click them individually.
Run all unit tests with just one Cargo command.
Upgrade Cargo to get https://github.com/rust-lang/cargo/pull/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 -->
