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
We just did the same for Linux64. Windows CI for this configuration
appears to be happy. So let's do it.
MozReview-Commit-ID: 9MmT2jzNGhQ
--HG--
extra : rebase_source : cb2edf5ffcef5aa1937ff002a5b6f843e877b575
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
Before bug 1373150, the l10n mozconfigs would include
compilation-related mozconfigs, which include setting compiler paths,
and setting --target for cross builds. After bug 1373150, the
compilation-related mozconfigs are not included anymore, which made
--target unset for l10n builds, leaving it to configure to guess what it
is based on the host. Which for cross builds is Linux, so configure
would set things up for a linux build, which doesn't work to do osx
l10n repacks.
So we add back an explicit --target to those mozconfigs, without
including all the compilation-related things.
We set the target to x86_64-apple-darwin, which is the same as what was
set through build/macosx/cross-mozconfig.common. This is different from
what the native osx builds would get (x86_64-apple-darwin11.2.0), but
the extra version in that target is actually not relevant and native
builds shouldn't care that it's gone.
Before bug 1373150, the l10n mozconfigs would include
compilation-related mozconfigs, which include setting compiler paths,
and setting --target for cross builds. After bug 1373150, the
compilation-related mozconfigs are not included anymore, which made
--target unset for l10n builds, leaving it to configure to guess what it
is based on the host. Which for cross builds is Linux, so configure
would set things up for a linux build, which doesn't work to do osx
l10n repacks.
So we add back an explicit --target to those mozconfigs, without
including all the compilation-related things.
We set the target to x86_64-apple-darwin, which is the same as what was
set through build/macosx/cross-mozconfig.common. This is different from
what the native osx builds would get (x86_64-apple-darwin11.2.0), but
the extra version in that target is actually not relevant and native
builds shouldn't care that it's gone.
--HG--
extra : rebase_source : 79d1616f0cc8291fbc3432165891fdfe8f221f95
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
sccache changes "--showIncludes" to "--show-includes" which clang-cl
doesn't understand. According to the owner's comment, this is because
it doesn't actually support clang-cl, disable it for now.
MozReview-Commit-ID: 3uK0CF9Tgyv
--HG--
extra : rebase_source : dabef27962fb3406e2c1f3c29aa6fe9c0174e2e5
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
sccache doesn't actually support clang-cl currently, so we're just making
our clang-cl builds slower by enabling it. Also, I'm trying to update to
a newer version of sccache and something broke running sccache+clang-cl
entirely so my try builds are busted, so disabling it entirely until
we actually support this configuration seems sensible.
MozReview-Commit-ID: LMkVuBRclCp
--HG--
extra : rebase_source : 76357d16190a6d2b2c5f177874de00ed3e636a76
These mozconfigs are no longer used since we stopped doing universal
builds in bug 1295375.
MozReview-Commit-ID: Izz9q1dRskH
--HG--
extra : rebase_source : a7b6f84d56812f0946c78aa054f116747e798300
J. Ryan Stinnett
Mike Hommey
Ralph Giles
Wes Kocher
Chris Peterson
Rail Aliiev
Marco Castelluccio
Chris AtLee
Gregory Szorc
Greg Mierzwinski
Chris Manchester
Ting-Yu Chou
Nathan Froyd
Kartikaya Gupta
rforbes
Andreas Tolfsen
Bobby Holley
Jordan Lund
Ben Hearsum
Ted Mielczarek
Justin Wood
Mike Shal
Mitchell Hentges
Carsten "Tomcat" Book