We need mozharness configurations and mozconfigs for rusttests. We are
explicitly not doing Windows debug configurations currently because of
peculiar link errors in such configurations.
A followup change will be adding a new automation step that wants to be skipped
in artifact builds, and this will make that simpler.
MozReview-Commit-ID: 5xwRB9eCRQn
--HG--
extra : rebase_source : 2fccd9d128ab92c98515762a62a0a2e89bf9ca24
extra : source : a02695cbf5762eb0eb7087239319807eb447ca1e
A followup change will be adding a new automation step that wants to be skipped
in artifact builds, and this will make that simpler.
MozReview-Commit-ID: 5xwRB9eCRQn
--HG--
extra : rebase_source : 0b5b5087eddbf030161482f054ddd4d7cc08ffd4
Bug 1374748 removed Stylo-specific builds, but there are still a few config
files left behind that are now unused. This cleans them up.
MozReview-Commit-ID: EAUx7YKQBmN
--HG--
extra : rebase_source : 7e2124f7e5625d25efc5e868e151dbdc02cfba65
Build Stylo (the styling system from servo) by default in all
builds for win32, win64, macOS and linux64 targets. It was
previously enabled for automation builds, so this just changes
the behaviour for local developer builds.
Note that this introduces a new dependency on libclang for the
binding generator. If you're developing on a tier-1 platform,
run `./mach boostrap` to install a working copy. Otherwise
llvm+libclang 4.0.1 is recommended.
Remove the explicit --enable-stylo=build in mozconfig.stylo
in favour of the configure default.
Add mozconfig.stylo to the hazard and debug-asan mozconfigs
so LLVM_CONFIG is defined properly for those builds.
Based on a patch by Bobby Holly in bug 1356991.
MozReview-Commit-ID: C2wRNl7JHpz
--HG--
extra : rebase_source : 1ed7c36a64e25b235a26864592cd7ea969a4cd25
We want most builds to be actually using sccache, so we include
mozconfig.cache from mozconfig.common. However, since the --with-ccache
configure option doesn't exist on non-compile jobs (e.g. artifact
builds), we move to using the CCACHE environment variable instead, which
allows us to unset it in mozconfig.no-compile.
And since mozconfig.no-compile is always included where no_sccache is
set, we can remove that variable.
--HG--
extra : rebase_source : a8c743de1fd7a3c0fbc53f7c233df36585897767
LLVM_CONFIG, per the contents of toolkit/moz.configure, is tied to
--enable-stylo, but it currently is set on all types of builds. It
currently happens to work, but it's actually not meant to, and sure
enough, the fix for bug 1374727 exacerbates that.
So we create a new mozconfig.stylo file that enables stylo and sets
LLVM_CONFIG, such that only build types that do enable stylo have
LLVM_CONFIG set.
--HG--
extra : rebase_source : 01277a79951888046c0b8e29c61cfc3b049ee0f0
This adds the mozconfigs, mozharness configs and taskcluster changes required
to create optimized DMD builds for linux64, win32, win64 and macosx64.
These builds will happen nightly on mozilla-central
We also add support for custom build variants on Windows (or other generic
worker environments).
MozReview-Commit-ID: HrVT9PLSWVx
--HG--
extra : rebase_source : 39ac752a312afe04187728da82a4a7f722634811
This patch enables talos test suites to run on VM (taskcluster) and also enables these test suites to run with GCOV code coverage instrumentation on the linux64-ccov build.
MozReview-Commit-ID: 7p59zvra1ge
--HG--
extra : rebase_source : 990ebecb9daaee7c5030e08b0d763493103f0fe8
The in-tree mozconfigs for Linux64 have been updated to build
Stylo by default. Stylo is still disabled in builds.
The existing Stylo Linux64 platform still exists. It still
uses its own mozconfigs. These mozconfigs source the mozconfigs
changed in this commit. This results in both --enable-stylo=build
and --enable-stylo being passed to configure. The latter takes
precedence.
This commit stops short of implying --enable-stylo=build as
the configure default for Linux64. I'm not sure if we're ready
to make that leap just yet.
MozReview-Commit-ID: K8rafDMlAGu
--HG--
extra : rebase_source : 7a3f7b63429bb2db18988478c0f4e7012b5ddee9
extra : source : 471a163b37d092fc5bf7a56bcf5c5295f727b8d8
The in-tree mozconfigs for Linux64 have been updated to build
Stylo by default. Stylo is still disabled in builds.
The existing Stylo Linux64 platform still exists. It still
uses its own mozconfigs. These mozconfigs source the mozconfigs
changed in this commit. This results in both --enable-stylo=build
and --enable-stylo being passed to configure. The latter takes
precedence.
This commit stops short of implying --enable-stylo=build as
the configure default for Linux64. I'm not sure if we're ready
to make that leap just yet.
MozReview-Commit-ID: K8rafDMlAGu
--HG--
extra : rebase_source : 5d32735f2574fae3bc9a396a06efa745d8fd1fb7
A number of developers find it convenient to build with
--disable-optimize --enable-debug for an improved debugging experience.
We don't currently have a configuration in CI that ensures this
combination of options works, so various changes break builds with this
configuration every so often. We should test such configurations to
ensure they build to provide a smooth experience for developers.
As of bug 1342503 being fixed, all of our desktop firefox builds have
webrender compiled in by default. Webrender can therefore be enabled at
runtime either by a pref or environment variable on any desktop firefox
build. The old builds that we originally used to stand up webrender are
no longer needed, as the *only* difference between them and the regular
builds are that they build with the pref turned on instead of turned
off. This doesn't warrant keeping around these extra builds, and this
patch removes them along with all the associated goop that was needed to
configure them.
MozReview-Commit-ID: 5wlOWo11fEk
--HG--
extra : rebase_source : 696afdd2d9fb5f7932d0737a7d71c3aa6af0bd64
One of the Rust crates that is built as part of geckodriver's dependency
chain uses a build script to compile some C code.
Because mozbuild does not yet pass the compiler wrapper down to where
the gcc crate can find it, we need to avoid building on geckodriver when
this is the case.
When compiling the browser for the rooting hazard analysis build (labelled
H on Treeherder), the MOZ_HAZARD environment variable will be set and
available to moz.build descriptions.
MozReview-Commit-ID: GprFKtvXvOE
--HG--
extra : rebase_source : f45aa5d8c86673c8287371efcfa703755c2b2073
This avoids some known hazard from replace-malloc itself, and unhides
--disable-replace-malloc hazards if there are any (and there is one from
bug 1361258), which wouldn't be caught until riding trains
(replace-malloc being only enabled on nightly).
The hazard from bug 1361258 that disappears is this one:
Error: Indirect call malloc_hook_table_t.jemalloc_thread_local_arena_hook
Location: replace_jemalloc_thread_local_arena @memory/replace/replace/ReplaceMalloc.cpp#261
Stack Trace:
jemalloc_thread_local_arena @ memory/build/replace_malloc.c#287
Gecko_SetJemallocThreadLocalArena @ layout/style/ServoBindings.cpp#2062
The new hazard from that bug is:
Error: Variable assignment jemalloc.c:arenas_map
Location: jemalloc_thread_local_arena @memory/mozjemalloc/jemalloc.c#3068
Stack Trace:
Gecko_SetJemallocThreadLocalArena @ layout/style/ServoBindings.cpp#2048
Where arenas_map is a thread-local variable, so there really is no
hazard.
--HG--
extra : rebase_source : bea3d2f862ede8c0b90775b6ec9cebb657b9b455
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.
Chris AtLee
Nathan Froyd
Marco Castelluccio
Christian Holler
Mike Hommey
Andrei Obreja
Ted Mielczarek
Wes Kocher
J. Ryan Stinnett
Ralph Giles
Chris Peterson
Greg Mierzwinski
Gregory Szorc
Chris Manchester
Kartikaya Gupta
rforbes
Andreas Tolfsen
Bobby Holley
Jordan Lund
Ben Hearsum
Rail Aliiev
Mitchell Hentges
Benjamin Smedberg
nfroyd@mozilla.com
aleth
Maja Frydrychowicz
Kim Moir
Justin Wood
Dustin J. Mitchell
Mike Shal
Carsten "Tomcat" Book
Alessio Placitelli
Georg Fritzsche
Steve Fink
Ehsan Akhgari
Nicholas Nethercote
Ryan VanderMeulen
Stephen A Pohl
Brian R. Bondy
Terrence Cole
Birunthan Mohanathas
Andrew Halberstadt
Julian Seward
Randell Jesup
Massimo Gervasini
Trevor Saunders
Ehsan Akhgari
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