Both BuildMonitor and BuildOutputManager are doing similar things and
wrapping the build with forms of monitoring. These classes are only
used in the `mach build` command.
Since the BuildOutputManager takes an instance of BuildMonitor as an
argument and since BuildOutputManager behaves as a context manager,
it makes sense for BuildOutputManager to control the lifetime of
BuildMonitor's collection.
So, we teach BuildOutputManager's context manager to start the
BuildMonitor and ensure its resource collection is stopped when it
exits.
MozReview-Commit-ID: 3l9Hwz0Xe7o
--HG--
extra : rebase_source : 600b0231fce050465bdccb2bc11680f77bbc35d9
r?gps for the build changes and ochameau for the rest.
This results in about a 28% speed-up for Jetpack mochitest runs, for me.
MozReview-Commit-ID: K30q7BfvTLs
--HG--
extra : rebase_source : 8074947062c73a329f1d8a255a9601147ba1ba0c
ccache 3.3 added two fields in the status.
1. "cache hit rate"
https://github.com/ccache/ccache/issues/94
2. "cleanups performed"
0769ea3630
We just teach the parser the two fields. Nothing else.
MozReview-Commit-ID: 9kZrDrpCopd
--HG--
extra : rebase_source : ecb55fa9187abb37e668f0d25b40afd41597f7f8
In our current Rust world, we have the following dependency structure:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust
|
+--> gkrust-gtest
This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so. So we have to do something different.
Our new structure is:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
| |
+--> gkrust-gtest --------------+
and we enforce that a given shared library can only have at most one
Rust library that it depends on. Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well. (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)
This patch allows specifying an objdir path in `SYMBOLS_FILE`, with the
requirement that the file is also listed in `GENERATED_FILES`. This is used
for handling NSS' .def files with their special processing.
I added tests for the existing `SYMBOLS_FILE` case as well as the new case
and a test for the error if the file is not listed in `GENERATED_FILES`.
MozReview-Commit-ID: 3cVbKplltfb
--HG--
extra : rebase_source : 0ae4180dbe9383b09f14554bfda8aec20d7cc094
Now that we access WPT related files from a source checkout, we no
longer need the web-platform tests zip file produced or consumed by
automation. So stop producing it.
MozReview-Commit-ID: Ea8KjKZJ5Yx
--HG--
extra : rebase_source : f22506a02fdd5e78434cdc5d1c1f274db1cd04e2
When attempting to run mach from a make target, there were failures on OSX due to an objdir
mismatch:
https://dxr.mozilla.org/mozilla-central/rev/7c576fe3279d87543f0a03b844eba7bc215e17f1/python/mozbuild/mozbuild/base.py#656
The two detected objdirs were "<objdir>" and "<objdir>/x86_64". I believe this should not
count as a mismatch, otherwise it would not be possible to run a mach command from the
x86_64 directory.
MozReview-Commit-ID: CXDEABNWX8L
--HG--
extra : rebase_source : 9daeaf372d872921e7b2854eee0313b5adc0e707
This command is mostly just a wrapper around `cargo vendor`, but it runs
it the right way and will install the cargo-vendor tool if necessary.
Additionally, the mach command will by default error if there are uncommited
changes to files other than Cargo.{toml,lock} in your working copy, and it
will stage changes to the vendored crates in your VCS after the update.
MozReview-Commit-ID: 2fMDBawNUMO
--HG--
extra : rebase_source : fe72f26aec795eb663c554933432e700ac5089c3
I wanted to be able to do some VCS interaction from a mach command, and we
didn't have anything suitable, so I tore up mozversioncontrol and replaced
it with a framework to hang new features off of. I've only implemented
the bits I need currently (get_modified_files and add_remove_files),
but it should be straightforward to add more functionality there.
This patch also adds a `repository` property to `MozbuildObject`, which will
return a `Repository` object for the topsrcdir to make using these helpers
even easier for `MozbuildObject`-derived classes.
MozReview-Commit-ID: Gw6Ixp1ltiN
--HG--
extra : rebase_source : e619d6642eb86c3f96e679ac22a3e561dfdbb56a
This is a little tricky since tup expects rules in a single Tupfile to
be topologically sorted, and the emitter emits the GeneratedFile object
before it emits the FinalTargetPreprocessedFile object. We work around
this by delaying when we process the application.ini.h GeneratedFile
object, but it's a hack.
MozReview-Commit-ID: 8nVm76nZOKb
--HG--
extra : rebase_source : a82cfbeef739aac791998fb6d45cf88eb7116e32
Eugen Sawin
Phil Ringnalda
aleth
Mike Hommey
Chris Manchester
Grisha Kruglov
Gregory Szorc
Kris Maglione
Mike Shal
Ting-Yu Lin
Nathan Froyd
Kartikaya Gupta
Michael Kaply
Ted Mielczarek
Sebastian Hengst
Carsten "Tomcat" Book
Wes Kocher
Andrew Halberstadt