Missed this in the update in bug 1382743. Thanks to glandium
for pointing out the oversight.
MozReview-Commit-ID: 6P4qnBCNEGy
--HG--
extra : rebase_source : d4b540d27ffaaa2edf5554a641dfc99fc93e9b92
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
The MinGit tooltool package used for Windows builds comes straight from
https://github.com/git-for-windows/git/releases/
This builds the version currently used on automation.
--HG--
extra : rebase_source : dbc2a36b07611e673d6661032ad53123a688d422
New upstream stable release.
Unions (untagged enums) for (unsafe) interoperability with C.
The `break` keyword can yield an expression value from a `loop`.
Non-capturing closures coerce to function pointers.
Numeric initializers for tuple structs.
MozReview-Commit-ID: 6TMjzXZuBKg
--HG--
extra : rebase_source : 3596ad4a1a1e299a4520fe064389912aeb986968
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
As of bug 1373150, l10n repacks do not require a anything to compile, so
they can stop downloading most toolchains from tooltool. However some
tools are still required, such as mozmake on Windows and DMG-related
tools on cross OSX.
--HG--
extra : rebase_source : f46e851c7941491530ce65490d0cfce4f9f02e35
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
Reduce development drag by requiring the most-recent-but-one
stable Rust release. This version is packaged for most
distros, but lets us use more recent library and language
features and spend less time finding work-arounds.
MozReview-Commit-ID: 4W3vkjlKoTu
--HG--
extra : rebase_source : 3828a8be964081bedb2857f9f71f4cd99f75c8be
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
We updated win64 builders to rust 1.18 while it was still in
beta to pick up better crash reporting. Bump those builds to
the stable toolchain now that it's released.
MozReview-Commit-ID: 1LlmrDfLfWL
--HG--
extra : rebase_source : 4c14198cf962db26a072cd4b6316edbe870cf5bd
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.
Update official builds for 64-bit Windows to use
1.18.0-beta.4 (0308c9865 2017-05-27). This picks
up a fix to unwinding with panic=abort which gives
us better crash reporting on that platform.
MozReview-Commit-ID: HLZSixr8Sxe
For a long time, we've kind of forced the GCC version used to compile
Firefox on automation to the minimum version we do support, because
using a newer version would pretty much guarantee that builds with older
versions would break.
Ideally, the same would be true of rust, but it's not the case, and sure
enough, building with older versions breaks. The most recent example is
bug 1367734 making rustc 1.17.0 required but leaving configure checking
for version 1.15.1.
There are multiple reasons why we'd want to use newer versions of rust
to build shipping versions of Firefox other than language requirements,
but we should still ensure building with supported versions of rust
doesn't break silently.
Here we add a set of new linux jobs that build opt and debug build with
the baseline of supported toolchains. At the moment, that's GCC 4.9,
rust 1.15.1, and clang 3.9 (for bindgen). That's a copy of the current
toolchains used for normal linux jobs, with rustc downgraded to the
package used after bug 1338311.
Further down the line, we'll be able to bump the versions of GCC, rust
and/or clang for the shipped Firefox builds, while keeping those jobs on
GCC 4.9, rust 1.15.1 and clang 3.9, until we do intentionally want to
bump those versions (as well as the corresponding configure checks).
--HG--
rename : browser/config/tooltool-manifests/linux64/releng.manifest => browser/config/tooltool-manifests/linux64/base-toolchains.manifest
extra : rebase_source : 33f609f44c1e70cf970ec8af328e0408e01ec0d2
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
The old archive was uploaded with internal visibility. This was almost
certainly a mistake.
I downloaded the old archive and produced a new one and re-uploaded it to
tooltool with public visibility. I had to reproduce the archive because
tooltool won't let you promote an existing item to public.
It appears that environment state and possibly differences in the
tar command result in diverging tar archives. For example:
==> clang.orig <==
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/bin/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/include/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/lib/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/libexec/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/man/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-build/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-view/
==> clang.new <==
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/bin/
-rwxr-xr-x gps/gps 18099 2017-02-01 20:15 clang/bin/git-clang-format
-rwxr-xr-x gps/gps 6731340 2017-02-01 20:33 clang/bin/llvm-mc
-rwxr-xr-x gps/gps 2241688 2017-02-01 20:34 clang/bin/obj2yaml
-rwxr-xr-x gps/gps 17105264 2017-02-01 20:33 clang/bin/llvm-c-test
-rwxr-xr-x gps/gps 13153616 2017-02-01 20:33 clang/bin/bugpoint
-rwxr-xr-x gps/gps 49666672 2017-02-01 20:33 clang/bin/clang-3.9
-rwxr-xr-x gps/gps 52901 2017-02-01 20:15 clang/bin/scan-build
-rwxr-xr-x gps/gps 6214036 2017-02-01 20:30 clang/bin/llvm-ar
Content within should be identical. It's just the file ordering and
owner bits that are different. This shouldn't matter.
MozReview-Commit-ID: HOzNXAd7xwq
--HG--
extra : rebase_source : 92650cbd1869b744a5f6a1d3534fb512f85b32d1
Update tooltool manifests for official builds to use repacks
of the upstream rustc 1.17.0 (56124baa9 2017-04-24) stable release.
These repacks include cargo 0.19.0-beta.1 (03efb7fc8 2017-04-23)
to include support for the RUSTC_WRAPPER environment variable
needed for use of sccache with rust code.
MozReview-Commit-ID: L9Nq2iK4GK8
--HG--
extra : rebase_source : 882b201282a0e13ed77ec5876972657eab81a562
Update tooltool manifests to reference rustc 1.16.0 stable repacks
which include cargo 1.19.0 nightly builds from 2017-04-19 which
support the RUSTC_WRAPPER environment override.
We're shipping with an unstable cargo while this feature makes its
way to release because it is necessary for deploying sccache support
for rust language code in our build and test automation.
MozReview-Commit-ID: Iow2894OPq7
--HG--
extra : rebase_source : f1a8e6cab612714f7b73ca8a14d14cabe9f4aef7
The version we update to is the current result from the
macosx64-cctools-port toolchain job.
(gotten with `mach artifact toolchain --from-build macosx64-cctools-port --nounpack`
and uploaded to tooltool)
--HG--
extra : rebase_source : 5d980012de2dfab0556ccb7ed27c434047054523
They are, in fact, the same version already, built from the same version
of clang-static-analysis-linux64.json, but one comes from a now expired
try build, and the other from a build on mozilla-central, that can still
be traced down:
https://tools.taskcluster.net/task-inspector/#Ro1bUCv4Svu2OWuQsOF_hA/0
--HG--
extra : rebase_source : 776314cecb3cba7043a02f4e1f2f4feb4b51731c
Also use the same cctools as cross-mac builds of Firefox.
Do dummy changes to the corresponding build scripts so that the builds
are force triggered (toolchain builds are not triggered automatically
when the tooltool manifest they use changes yet).
--HG--
extra : rebase_source : 699143de819c29c98ca31308ac502f9331123403
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
The mercurial revision of sixgill listed in the manifest doesn't exist,
so I took what looks like corresponds to the last change to the tooltool
manifests, in order to avoid any other difference than GMP linkage.
This was built manually on a one-click-loaner.
--HG--
extra : rebase_source : 5ea830e48a6424a6ded9beab0628d0e562251c47
These mozconfigs are no longer used since we stopped doing universal
builds in bug 1295375.
MozReview-Commit-ID: Izz9q1dRskH
--HG--
extra : rebase_source : a7b6f84d56812f0946c78aa054f116747e798300
Apply a 2-character indent to in-tree tooltool manifests to make
them easier to read, and to make the formatting more consistent
so automating updates is simpler.
Modern editors will maintain json indentation. The only long
lines we have are already over 80 characters, so the extra space
shouldn't create new long lines.
Also update mercurial installer script to generate json with
the same indentation, even though its output is temporary.
Tooltool itself was updated to generate manifests with this
indentation in Bug 1325225.
MozReview-Commit-ID: DKj6nL9OENv
--HG--
extra : rebase_source : fc3f8616ec689d74e06c0db84c2b261825f86453
Update to the point release. These are repacks of the
upstream builds for 1.15.1 stable with appropriate
libstd builds for each target.
This incorporates the -fPIC fix for linux32 so we can
use upstream builds instead of our patched toolchain.
It also corrects the signature of vec::IntoIter::as_mut_slice
which was incorrect in 1.15.0.
MozReview-Commit-ID: JvEdGPwgS03
--HG--
extra : rebase_source : 9edd9970d8328274311493c2c3c4fffa97b258a9
Use a custom build of rust 1.15.1 with an additional bump of the
gcc crate to 0.3.43 to pass -fPIC to the C compiler on i686-linux.
While 1.15.1 was tagged today, there's some question as to whether
it would be released from the tag or if the tag would be moved
to incorporate this fix.
This works around the issue with text segment relocations with
the 1.15.0 stable release. For more information see the upstream
issue at https://github.com/rust-lang/rust/pull/39523
MozReview-Commit-ID: 83IxtJeJxlh
--HG--
extra : rebase_source : 8deda9058c77a98c65a46949768702c56296d9d4
Repack of the upstream builds of the rust 1.15.0 stable release.
MozReview-Commit-ID: KDjkSQSFrFA
--HG--
extra : rebase_source : 7ca562b3d1cc4d051d9cfc25ef14fbbe2dbd77bb
Mike Hommey
Wes Kocher
Ralph Giles
Chris Peterson
Rail Aliiev
Marco Castelluccio
Chris AtLee
Ted Mielczarek
Gregory Szorc
rforbes
Greg Mierzwinski
Chris Manchester
Ting-Yu Chou
ffxbld
Sebastian Hengst
Nathan Froyd
Kartikaya Gupta
Andreas Tolfsen
Bobby Holley
Jordan Lund
Ben Hearsum
Mike Shal
Justin Wood
Mitchell Hentges
Carsten "Tomcat" Book
Christian Holler
Jeff Gilbert
Alin Selagea
Jesse Schwartzentruber