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
Collect common options used in artifact build tests in a single
mozconfig so they can be set more consistently.
Use this to make unsetting toolchain defines universal in these
tasks, fixing fallout from bug 1283898 which defined CARGO and
RUSTC everywhere, conflicting with --disable-compiler-environment
just like CC and CXX were conflicts in some artifact tasks.
MozReview-Commit-ID: 4SbxByjClQb
--HG--
extra : rebase_source : d8a48fd2192ceb5ece76c827e2243ae784b991cb
Now that bug 1283898 has landed, we build rust code by default.
Mention the --disable-rust option until it goes away.
MozReview-Commit-ID: 1CYq9xSuU19
--HG--
extra : rebase_source : fbe3b63a3852c016f20222d0df2a4ed642716c64
Spidermonkey doesn't currently depend on rust code, and this
unblocks enabling rust by default on gecko builds until we
can get the appropriate toolchain hooked up to all of the
SM automation jobs.
The include must be conditional to avoid breaking artifact builds.
MozReview-Commit-ID: 1PmcFvcZLM2
--HG--
extra : rebase_source : 1a22232e064dd253b80ebaa55decfde1ba7e1ea0
Include mozconfig.rust in the common mozconfig so all jobs
will have the same rust config.
Automation mozconfigs all inherit from mozconfig.common,
so we can include mozconfig.rust there and not need it
anywhere else.
Remove --enable-rust from mozconfig.rust now that it's
the default. We only need the RUSTC and CARGO path
variables so jobs can find the toolchain installed from
the tooltool manifest. Also some automation jobs reject
the configure option if we set it unconditionally.
The --enable-rpath comment is no longer necessary; rust has
been consistently built this way for some time.
MozReview-Commit-ID: 2IeIIIinnPL
--HG--
extra : rebase_source : 79dadcc5ed13f2db312042d755a57698f267e902
Switch from --enable-rust to optionally enable rust code
to --disable-rust to optionally disable it.
MozReview-Commit-ID: C8cQr5MXUzV
--HG--
extra : rebase_source : 0372be3cc3da56b49104b80c41974139a488ecb2
Ryan VanderMeulen
Chris Manchester
Geoff Brown
Ehsan Akhgari
Phil Ringnalda
Wes Kocher
Carsten "Tomcat" Book
Mike Hommey
Randell Jesup
Nathan Froyd
Alessio Placitelli
aleth
Makoto Kato
Masatoshi Kimura
Ting-Yu Chou
Ralph Giles
Till Schneidereit