This was accidentally overlooked in 1e0bcb0402b5 (bug 1231764).
MozReview-Commit-ID: IYxrRV9G5iW
--HG--
extra : rebase_source : 7ee0619fecc5b06e1dd6f1d2ef4ab23c21ce686c
CLOSED TREE
Backed out changeset 01cfc71ce542 (bug 1322735)
Backed out changeset 84c729c41230 (bug 1322735)
Backed out changeset b419aaefae95 (bug 1322735)
It turns out that running makecab to compress PDB files takes a significant
amount of time in the buildsymbols step. I wrote an implementation of
makecab in Rust that implements only the subset of features we use and
it's significantly faster:
https://github.com/luser/rust-makecab
This patch adds a makecab check to moz.configure, adds a release build of
the makecab binary to the Windows tooltool manifests, points the build at
it from mozconfig.win-common, and changes symbolstore.py to use MAKECAB
from substs instead of calling `makecab.exe` directly.
MozReview-Commit-ID: 76FHLIZFCXS
--HG--
extra : rebase_source : af4cf2e4db4607ec9329b2811cc0175d3e113b66
Dumping symbols can interfere with staging cppunittests in case calling
objcopy from the symbol dumping script coincides exactly with calling
objcopy when staging cppunittests when the two are run in parallel. This
patch prevents symbol dumping from happening while tests are being packaged.
MozReview-Commit-ID: Hgi1zyIZE7K
--HG--
extra : rebase_source : 5fac1ff8aeacde38e27ca0ca7f33ed9a594dc06b
Android tests use dumpsys to determine the current "top activity";
if Firefox is not in the foreground, tests are considered complete.
But dumpsys is heavy-weight and can fail, for reasons unknown. With
this patch, test harnesses continue to use dumpsys to determine the
top activity, but call it much less often: If the harness has just
received new test output, the harness assumes that tests are in
progress and does not check the top activity.
Instead of relying on the assumption that a previous run of CMake was
using the same arguments, remove the CMake cache file and re-run it.
This way the script is robust no matter what kind of build directory
existed from before.
Since individual config files have different source repos declared,
it's better to deal with each individual source directory separately.
Also make sure to revert any of the existing changes in each directory
so that attempts to apply patches to the source directory or import
our static analysis checks into clang-tidy are guaranteed to always
succeed.
Many people have been shooting themselves in the foot for too long by
including in-tree mozconfigs.
This change adds a guard that makes it an error when this happens on
builds not running on automation.
Analysis of the in-tree mozconfigs indicate that
build/mozconfig.automation is properly included by the in-tree
mozconfig that matter, directly or indirectly.
The only ones that don't include it are:
b2g/config/mozconfigs/common.override
b2g/graphene/config/mozconfigs/common.override
browser/config/mozconfigs/linux64/source
browser/config/mozconfigs/win64/common-win64
build/mozconfig.cache
build/mozconfig.clang-cl
build/mozconfig.common.override
build/mozconfig.rust
build/mozconfig.vs-common
build/mozconfig.win-common
build/unix/mozconfig.gtk
build/unix/mozconfig.stdcxx
build/win32/mozconfig.vs-latest
build/win32/mozconfig.vs2015-win64
build/win64/mozconfig.vs-latest
build/win64/mozconfig.vs2015
mobile/android/config/mozconfigs/common.override
which are either empty for use in try builds (override files), or would
already cause great pain if they were directly included, so there's
little chance they would be.
--HG--
extra : rebase_source : 0e6accf241759f8d44868f253874f6546dbadb52
Mike Hommey
Gregory Szorc
Andrew Halberstadt
Carsten "Tomcat" Book
Eric Rahm
Jonathan Kew
aleth
Ryan VanderMeulen
Jan Beich
Phil Ringnalda
Daniel Stenberg
Ted Mielczarek
Sylvestre Ledru
Chris Manchester
Geoff Brown
Ehsan Akhgari
Wes Kocher
Randell Jesup