While this looks like going backwards, it is desirable to build clang
against GCC 4.8, such that it contains its libgcc. This, in turn, will
solve problems using clang 3.9 with static-analysis builds (details in
bug 1356926). Another way to fix those problems would be to build clang
3.8 but that too would require GCC 4.8. Upgrading those builds to clang
3.9 will also allow to enable stylo on them.
It becomes a library of some sort, so that multiple scripts can benefit
from it to build different versions of GCC.
The GPG key associated with GCC is also refreshed from keys.gnupg.net,
adding a new subkey, used to sign newer versions of GCC (and
postprocessed with pgpstrip to make it smaller).
We're soon going to build multiple versions of clang and gcc for linux,
and we need to differentiate them. Furthermore, there is a need for the
base-toolchains builds to use a fixed version of clang and gcc. So
rename the clang and gcc toolchain jobs to include their version, add
aliases to satisfy all existing jobs, and adjust the base-toolchains
jobs to use the explicit version.
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-3.9-linux64.json
rename : taskcluster/scripts/misc/build-gcc-linux.sh => taskcluster/scripts/misc/build-gcc-4.9-linux.sh
Those resources are used to compute a unique identifier for the
toolchain, and changes to those files will change the unique identifier,
and lead to the toolchain being rebuilt.
Using wildcards, especially in the build-clang directory, makes all the
files from there used for the unique identifier, even files irrelevant.
The side effect is that any change to any json file for clang toolchains
currently triggers *all* clang toolchains to be rebuilt, which is a
waste of resources and time.
But while it is tempting to list all the files involved, it is also
tedious and error-prone. Specifically, listing the relevant patch files
for clang toolchain builds is bound to end up outdated. OTOH, we're not
trying to mitigate bad actors here, but just to avoid shooting ourselves
in the foot. And patch files are, in practice, not changed. The jsons
are changed to reference them or not, but the patches themselves don't
change in relevant ways. They may be updated for new versions of clang,
which require a json change anyways. So we ignore the patch files.
The premise for simply using the dependencies task names is that if the
name of dependencies changes, or their number, that will impact the
index path, forcing a new build. If there is no such change, but one or
several of the dependencies themselves have changes, they will get a new
build, which will force a new build for the job that depends on them.
In that latter case, the index path will be the same as before the
changes, but that is already what's happening today.
The build-clang script doesn't handle properly updating the svn tree
when it already exists and the svn url changed (which happens when using
different branches), so if a clang job somehow gets a host that happen
to have run another clang job before, it may not actually build what
was intended to be built.
That event, however, is rather rare, because clang jobs don't happen
regularly enough. Fast iterations on try can cause the problem to
appear, though.
The former makes the use of a cache kind of useless, and the latter
barely benefits from the cache anyways. So let's just solve this the
easy way and remove the use of the cache. The alternative would be to
fiddle with svn switch, and I don't really feel like it.
Eventually, those jobs should use some other source than svn anyways,
one that is more verifiable (tarballs for releases, and the git mirrors
for trunk).
We should turn on test_localeCompare.js again on Android since we use ICU.
MozReview-Commit-ID: 1H0DsKpWkId
--HG--
extra : rebase_source : d29564bfd20ee6fbc2eadf2f4b80066efc3deef0
extra : histedit_source : 294c17ea1736f196aca7aa969203428e6792625e
This adds a most recently used (MRU) cache for the most common base domain
requests (aAddtionalParts == 1). With a table size of 31 I saw 8777 hits and
22 misses when loading twitter, youtube, and techcrunch. In stress testing
this provided a 75% reduction in run time.
MozReview-Commit-ID: 3JgCwIZagMs
Use the UI thread's tid for checking if we're on the UI thread in Gecko.
This lets us get rid of `GeckoThread.registerUiThread`, in order to
avoid a race where we check for UI thread before `registerUiThread` is
called.
MozReview-Commit-ID: 11gAWgx4UZo
Sebastian Hengst
David Anderson
Mike Hommey
Wes Kocher
Joel Maher
Kris Maglione
Olli Pettay
Kim Moir
Tooru Fujisawa
Gabriel Luong
Ed Lee
Mike Conley
Dão Gottwald
Makoto Kato
Eric Rahm
ffxbld
Phil Ringnalda
Aaron Klotz
André Bargull
Sean Stangl
Jim Chen
Masatoshi Kimura
Geoff Brown
Jan de Mooij