We gave up on the iea of parallel tile rendering in favor of different approaches, so the job scheduler isn't used at all. The several seconds spend testing the job scheduler in each push is a waste of infra. In addition, rust is a better avenue to tackle this type of system.
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