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
The --disable-compile-environment configure option used by
the artifact builds removes all support for toolchains,
including setting paths for them with environment options.
Unset the RUSTC and CARGO vars inherited from mozconfig.rust
in the artifact mozconfigs to accommodate the invalid option
check, just like we do for the CC and CXX options.
MozReview-Commit-ID: IwPetRaIY25
--HG--
extra : rebase_source : 37fb4bf9e69d3082cc0ed6b0013e6363a7e8e8e5
Tasks calling these generally use tooltool and the hazard
manifest to provide toolchains, but the setup job doesn't
they don't use a mozconfig to configure paths, and the analysis
job uses a different TOOLTOOL_DIR.
The build calls configure, which defaults to --enable-rust,
so we need to add the correct rust toolchain path to the
environment like we do for C++.
MozReview-Commit-ID: gFnZ0SK1f7
--HG--
extra : rebase_source : f7cabb5b15551f5b00ff8271ceddeb4b47146c03
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
We add opt and debug mozconfigs that enable stylo.
We define 2 new mozharness build configurations for stylo builds. These
occur only on Linux64 for the moment.
The mozharness configs are mostly copypasta. This is how you do things
in mozharness land.
MozReview-Commit-ID: 99XNOymw9Dx
--HG--
extra : rebase_source : d89ddd907ed96697f62637859f6f719601e03b01
Upload symbols when --enable-artifact-build-symbols is specified.
Add --enable-artifact-build-symbols to artifact config for linux, linux64,
win32, win64, macosx64.
MozReview-Commit-ID: LpuwfzWXPBH
--HG--
extra : rebase_source : 137466aa3c8c327cf1932e012927fceb451d82ab
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : b2098e4d01039edd6cff37f3e6a26c2ed3d3d3ba
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : af40a6e582665ffcb575092586731f595a362ae4
Needed because buildbot clones/checks out from the repo head (of default)
and then updates to the rev for the nightly we're pulling, which can cause
CLOBBER file changes to initiate an unwanted clobber of the object directory
where we just pulled the nightly binary from. Even when CLOBBER hasn't actually
been touched in the changeset range we're looking at between nightlies.
MozReview-Commit-ID: 154d2iZeHgd
--HG--
extra : rebase_source : 504b821955a870cabf6fc727d13e44a33aabb45c
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
At the same time, we improve things slightly by deriving HOST_CC from CC
in a smarter way, as well as CXX from CC, which we weren't doing
previously.
Many related things are not moved at the same time to keep the patch
somehow "small".
The unix mozconfig.rust is actually completely generic now that we're
using toolchains built with --enable-rpath in tooltool.
Move the mozconfig.rust fragment up a level to reduce confusion.
Write a mozconfig.rust fragment which makes the rust toolchain
provided by tooltool available for linux builds, similar to
what we do for MacOS X.
Include this in linux64 mozconfigs to enable rust for official
nightly builds of that target. These aren't used outside of automation
builds, so including rust there will verify code on check-in
without requiring developers to install rust.
We must whitelist the mozconfig fragment to pass the consistency
check since we're not ready to let this feature ride the trains
to beta and release.
The tooltool reference is to a custom build of rustc 1.4
with --enable-rpath to avoid having to add the rustc lib
directory to LD_LIBRARY_PATH which somehow conflicts with
the gtk3 build we also install through tooltool.
It is also built with --enable-llvm-static-stdcpp on a
rust-buildbot dist docker image (centos:5 + script updates)
to avoid issues with GLIBCXX and GLIBC symbol versions.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
Some mozconfigs don't include mozconfig.linux*, and don't get gtk-related
definitions, so move them in a separate mozconfig. To avoid having two
files, one for 32-bit builds and one for 64-bit builds, rely on the
includer to set PKG_CONFIG_LIBDIR appropriately.
At the same time, move all the --enable-default-toolkit=cairo-gtk2 in that
new file in the case the gtk3 package wasn't pulled from tooltool.
Write a mozconfig fragment which makes the rust toolchain
provided by tooltool available for linux builds.
Use linux64 mozconfigs to enable rust for official builds of
that target. These aren't used outside of automation builds,
so including rust there will verify code on check-in without
requiring developers to install rust.
Using -O for valgrind builds optimizes the code slightly differently
than our default of -Os, which can lead to spurious build failures if
the compiler's warnings depend on the optimization level. Since using
-Os in the mozconfigs would just duplicate the settings in configure.in,
delete the --enable-optimize lines entirely and let the defaults work
for us.
'make check' is somewhat special in that we want to trigger testers
before it finishes. Since moving sendchange into mach is difficult and
'make check' may be going away in the future anyway, just pull it out
for now.
Also remove the MOZ_AUTOMATION_*_SENDCHANGE flags since we aren't using
them.
Backed out changeset efde4f7c20e5 (bug 1014134) to re-enable replace-malloc for the haz build. This patch fixes the reason for that disablement.
--HG--
extra : rebase_source : 2ae1c63bc088debb1b6191100d08f688acfb4135
DONTBUILD because nothing uses it yet. I will land a mozharness change later that will enable it.
--HG--
rename : browser/config/mozconfigs/hazards => browser/config/mozconfigs/linux64/hazards
It was only used to define -jN to control build parallelism. This is
now set automatically as of part 1 of this patch series and therefore
isn't needed.
Removes options that are now set by default (eg enable symbols, app=browser) and
those that have since been removed from configure (eg --disable-javaxpcom). Also
removes |--enable-jemalloc| if |--enable-trace-malloc| present, since the latter
force disables jemalloc regardless.
Note: This changeset is effectively no-op. No behaviour change is intended.
Ralph Giles
Gregory Szorc
Maja Frydrychowicz
Greg Mierzwinski
Wes Kocher
Kim Moir
Mike Hommey
Justin Wood
Dustin J. Mitchell
Ted Mielczarek
Mike Shal
Carsten "Tomcat" Book
Alessio Placitelli
Georg Fritzsche
Steve Fink
Chris Manchester
Jordan Lund
Rail Aliiev
Ehsan Akhgari
Nicholas Nethercote
Ryan VanderMeulen
Ben Hearsum
Stephen A Pohl
Brian R. Bondy
Terrence Cole
Birunthan Mohanathas
J. Ryan Stinnett
Nathan Froyd
Chris AtLee
Andrew Halberstadt
Julian Seward
Randell Jesup
Massimo Gervasini
Trevor Saunders
Ehsan Akhgari
Christian Holler
Ed Morley
Jonathan Griffin
Chris Cooper
Gavin Sharp
Joel Maher
L. David Baron
Gary Kwong
Malini Das
Mark Banner
Benoit Girard
Ted Mielczarek
Mounir Lamouri
Rafael Ávila de Espíndola
Ed Morley
John Ford