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
