Per schedule, bump the minimum-supported rust version to 1.21.0
two weeks after its stable release so we can use new code which
depends on it.
MozReview-Commit-ID: Bn8UjvTC7uw
Except ASAN builds, which for some reason fail with that version
(bug 1409267).
--HG--
extra : rebase_source : e91bd0f4cd152be57abd5cddb8e15e4af34912bb
New upstream release.
Maintain a linux64-rust-1.20 for use verifying the minimum-
supported rust version once we update it.
We still use rust 1.19 to build sccache since there are
network connection issues when it's built with more recent
rust releases.
MozReview-Commit-ID: 9KjdYAAQZRa
--HG--
extra : rebase_source : 48a9512351723c7cc9a3ac1414097811f2d93720
The only tricky piece here is that the resulting toolchain archive is
private, and uses a newly allocated Task Cluster scope
(queue:get-artifact:project/gecko/android-sdk/*) to restrict access to
the archive. All SCM levels (1, 2, 3) have been given the new scope:
see https://tools.taskcluster.net/auth/roles/moz-tree:level:1 and
friends.
MozReview-Commit-ID: CcDqDOHODpe
--HG--
extra : rebase_source : 81dbb065f2a3c4e7733e964be66adb1733db52c6
When adding sccache toolchain jobs in bug 1381772, building with gcc
failed, and building with clang worked, so I just went with the path of
least resistance. That's however a suboptimal position in the dependency
graph, so it's still preferable to use gcc if possible.
Looking exactly how it fails, it turns out it's because without CC being
set, ring wants to build with "cc", which ends up being the system gcc
instead of ours (our gcc archive doesn't provide "cc", only "gcc"), and
it is too old to support the compiler flags ring uses.
So setting CC does the trick.
--HG--
extra : rebase_source : 4c657664957dff1f7aebe470e0440a52c9e280e5
The only tricky piece here is that the resulting toolchain archive is
private, and uses a newly allocated Task Cluster scope
(queue:get-artifact:project/gecko/android-sdk/*) to restrict access to
the archive. All SCM levels (1, 2, 3) have been given the new scope:
see https://tools.taskcluster.net/auth/roles/moz-tree:level:1 and
friends.
MozReview-Commit-ID: CcDqDOHODpe
--HG--
extra : rebase_source : 062bca8c65556f0f46e9c9cc6cd81eb04cf2b522
New upstream stable release.
Maintain rust-1.19 builds for verifying the minimum-supported
version, and because we have network failures when we build
sccache with rust 1.20 or 1.21.
MozReview-Commit-ID: 5qi8JDTjfzj
Add a toolchain job description which calls the
repack_rust.py script to package the requested
upstream build of Rust and its standard libraries
for use in gecko builds.
Links are added to these new toolchains for various build
and analysis tasks as appropriate. The base-toolchain
tasks use an explicitly-versioned toolchain since those
can be different from the current release used for most builds.
The corresponding tooltool manifest entries are removed
now that taskcluster artifact versions are available.
This simplifies the update process since new toolchains
can be packaged and used automatically by just updating
the versions in the task descriptions.
A 'linux64-rust' toolchain can be added to other tasks
as a dependency and artifact. It supports linux64-
hosted builds of Rust code targeting linux64 or linux32.
A 'linux64-rust-macos' toolchain targets linux64-hosted
builds of Rust code targeting macOS on x86_64.
A 'linux64-rust-android' toolchain targets linux64-hosted
builds of Rust code targeting various Android architectures.
Two 'win64-rust' and 'win32-rust' toolchain tasks create
similar entries for Windows-hosted builds. All our automation
builds are hosted on win64, so we could use one artifact
with support for both targets, but currently this doesn't
work because of cross-compilation issues in some crates.
This patch maintains the previous separation between
win32 and win64 rust toolchains until that can be addressed.
MozReview-Commit-ID: GRiJml8CtzO
--HG--
extra : rebase_source : 09a3698ce7f9a8b5f2b5d9b5a1fde9c05dc6b540
The lesson learned from bug 1356926 and bug 1386588 is that the version
of gcc used to build clang matters, and that we can't bind the version
we use to build clang to the version we use to build Firefox.
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.
Those jobs now have all their dependencies installed through taskcluster
artifacts.
--HG--
extra : rebase_source : de311326999ea587e6885f0cb26c2d4a14110b00
Building linux64-clang-tidy doesn't use clang, and building
macosx64-cctools-port doesn't use gcc.
--HG--
extra : rebase_source : 78d7021fb56f22b3bbf3fad61032348a0d35f98c
None of the toolchain jobs are actually using sccache, so they don't
need the dependency. Those jobs also don't run frequently enough that
sccache would be a win for them, and when they do run, they're likely
to have few cache hits, if the cache is not expired anyways.
--HG--
extra : rebase_source : bddd0d0688303f9d9b117f4e2b952f22621bf9dd
This leaves out fuzzing and linux static analysis builds, which are
using, respectively, clang 4.0.1 and clang 3.8, while linux64-clang
produces a 3.9 and win*-clang a 5.0
--HG--
extra : rebase_source : 45128ac74bf4fe7e6a2ace57043c34ecdf0fe929
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
This affects the location of the artifacts directory, so adjust the
scripts and artifact definitions as a consequence.
--HG--
extra : rebase_source : 008b8cf33957eabfcacee61de8a260b5df146ab4
Ralph Giles
Phil Ringnalda
Mike Hommey
Sebastian Hengst
Nick Alexander
Steve Fink
Tom Ritter
Wes Kocher
Dustin J. Mitchell
Chris Manchester