History does not disclose why we needed this, but in the brave new GCC
6-compiled world, deleting these files means that host links can no
longer find libstdc++, which causes problems. Let's put the files back.
Depends on D22883
Differential Revision: https://phabricator.services.mozilla.com/D22884
--HG--
extra : moz-landing-system : lando
We're going to copy an x86_64-unknown-linux-gnu ld into the clang build,
which clang will then use in preference to things on PATH. We therefore
need to ensure that this ld is the same ld as would be used for other
builds, such as PGO. This change is the most expedient way to do that;
future work will make the gcc job(s) depend on linux64-binutils directly.
Depends on D22881
Differential Revision: https://phabricator.services.mozilla.com/D22882
--HG--
extra : moz-landing-system : lando
These toolchain tasks are the last ones using the historical
download-tools script from build/unix/build-gcc, which invokes gpg to
validate the downloaded tarballs. The consequence is that gpg-agent is
spawned and stays running, preventing a cleanup script from doing its
job, making the tasks fail.
Fetches are the new way to download sources, and can also do gpg
validation without those caveats.
The download-tools.sh script can then be removed as it's not used
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D22682
--HG--
extra : moz-landing-system : lando
The build script currently is doing some unnecessary steps:
- Running `gclient` only prints out an help message. It is a step
indicated in various documentations, but is only necessary to keep
depot-tools up-to-date, which they are, since we just cloned it.
- The `fetch v8` command creates a v8 directory, no need to create
another layer.
- `gclient sync` is run as part of `fetch`. Same as `gclient`, this step
is only given in documentations to keep things up-to-date on an existing
clone, but we just freshly got one.
- Same goes for `git pull && gclient sync`
- `git checkout master` is not necessary, as `fetch` gets us there
already (albeit, in a detached head state)
- install-build-deps.sh installs build dependencies for chrome or
whatever. That's way too much for v8, that barely needs pkg-config and
glib, which we now install in the docker image.
Differential Revision: https://phabricator.services.mozilla.com/D20082
Make some adjustments to make the build work:
- On Linux, a newer GCC is needed, and -lrt is missing for
clock_gettime.
- On Mac, ninja expect AR be accept ar arguments, which clang doesn't,
so use llvm-ar.
- On Windows, remove the /WX flag that upstream sets (warnings as
errors) because there _are_ warnings in the code, and remove the
explicit /MACHINE:x64 linker flag because we're building for x86.
(we could build for x64, but I'd rather leave that to a followup)
Differential Revision: https://phabricator.services.mozilla.com/D19911
It turns out version 15.4.2 spawns a vctip process that sticks after the
build, and since bug 1527798, that breaks unmounting caches because the
process has a handle on msvcp140.dll, which lies in the source
directory. The problem goes away with 15.8.4, so upgrade all toolchain
tasks to that.
That's the same version as we're using on x86/x86-64 MSVC builds.
Differential Revision: https://phabricator.services.mozilla.com/D19752
to give time to docker images and toolchains to build.
--HG--
rename : taskcluster/docker/debian-raw/cloud-mirror-workaround.sh => taskcluster/docker/debian-base/cloud-mirror-workaround.sh
rename : taskcluster/docker/debian-raw/setup_packages.sh => taskcluster/docker/debian-base/setup_packages.sh
Make some adjustments to make the build work:
- On Linux, a newer GCC is needed, and -lrt is missing for
clock_gettime.
- On Mac, ninja expect AR be accept ar arguments, which clang doesn't,
so use llvm-ar.
- On Windows, remove the /WX flag that upstream sets (warnings as
errors) because there _are_ warnings in the code, and remove the
explicit /MACHINE:x64 linker flag because we're building for x86.
(we could build for x64, but I'd rather leave that to a followup)
Differential Revision: https://phabricator.services.mozilla.com/D19911
It turns out version 15.4.2 spawns a vctip process that sticks after the
build, and since bug 1527798, that breaks unmounting caches because the
process has a handle on msvcp140.dll, which lies in the source
directory. The problem goes away with 15.8.4, so upgrade all toolchain
tasks to that.
That's the same version as we're using on x86/x86-64 MSVC builds.
Differential Revision: https://phabricator.services.mozilla.com/D19752
Similar to the previous patch, this adds two jobs. One that
cross-compiles the binaries produced by `cargo test` and publishes them
as an artifact. The other job downloads the artifact and runs the
resulting binaries.
Differential Revision: https://phabricator.services.mozilla.com/D19370
--HG--
extra : source : 79120d13e713114032263c0851455ec5f981d72c
One job (which runs on a Linux docker worker) cross compiles wrench in
two configurations (regular and headless) and publishes artifacts with
the binaries. The other job (which runs on macOS) downloads the
artifacts and uses them to run the WebRender macOS CI release-mode
scripts, which basically consists of running the WebRender reftest
suite.
Differential Revision: https://phabricator.services.mozilla.com/D19369
--HG--
extra : source : 028c0ed368b844a4e54f3c38177b0fe65211d484
The shebang at the top of fetch-content doesn't work on macOS because
the path to python3 is not /usr/bin. Using /usr/bin/env doesn't work
properly on all platforms either so instead we invoke the script using
the currently running python executable.
Differential Revision: https://phabricator.services.mozilla.com/D19744
--HG--
extra : source : f6413e576a2169855f766085704570c9fc851ee2
Similar to the previous patch, this adds two jobs. One that
cross-compiles the binaries produced by `cargo test` and publishes them
as an artifact. The other job downloads the artifact and runs the
resulting binaries.
Differential Revision: https://phabricator.services.mozilla.com/D19370
--HG--
extra : moz-landing-system : lando
One job (which runs on a Linux docker worker) cross compiles wrench in
two configurations (regular and headless) and publishes artifacts with
the binaries. The other job (which runs on macOS) downloads the
artifacts and uses them to run the WebRender macOS CI release-mode
scripts, which basically consists of running the WebRender reftest
suite.
Differential Revision: https://phabricator.services.mozilla.com/D19369
--HG--
extra : moz-landing-system : lando
The shebang at the top of fetch-content doesn't work on macOS because
the path to python3 is not /usr/bin. Using /usr/bin/env doesn't work
properly on all platforms either so instead we invoke the script using
the currently running python executable.
Differential Revision: https://phabricator.services.mozilla.com/D19744
--HG--
extra : moz-landing-system : lando
libclang 3.9 has a bug that makes bindgen unable to distinguish some typedefs
from the underlying type, which matters for bug 1523071.
We have had quite a few workarounds for this bug and I don't really want to add
more, since in this case it is non-trivial. I think requiring libclang 4.0+ is
reasonable at this point.
Of the distros that can't build Firefox out of the box with clang, dropping support
for clang 3.9 would only break Ubuntu 14.04 LTS, which support ends April 2019,
right before we release 67.
Differential Revision: https://phabricator.services.mozilla.com/D18889
--HG--
rename : build/build-clang/clang-3.9-linux64.json => build/build-clang/clang-4.0-linux64.json
rename : taskcluster/scripts/misc/build-clang-3.9-linux.sh => taskcluster/scripts/misc/build-clang-4.0-linux.sh
extra : moz-landing-system : lando
This produces the same executables (produced for the same platforms) as
those currently pulled from tooltool (modulo timestamps, maybe changes
since last manifest change, etc.). Unfortunately, as of currently, the
Windows variant needs to be cross-built with mingw because it doesn't
compile without some POSIX APIs that MSVC/Windows SDK don't provide.
One thing that is left out of this change is whether to be completely
accurate with the toolchain cache hash (requiring a large list of files
as resources, and making those built very frequently), whether we'd
rely on manual updates, or if we should go with completely uncached
tasks. This can be left for a followup, the tasks not being hooked up
to be actually used by other tasks yet.
Differential Revision: https://phabricator.services.mozilla.com/D16302
--HG--
extra : moz-landing-system : lando
Two new kinds are introduced - 'instrumented-build' and
'generate-profile'. The instrumented-build kind is almost identical to
the build kind, except it can be used earlier in the task graph. The
3-tier PGO process becomes:
instrumented-build -> generate-profile -> build
The final build stage is identical to any other build, except it has
the 'use-pgo' flag set to True in its task definition. This flag causes
the transforms to add the instrumented-build and generate-profile tasks
to the taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D15750
--HG--
extra : moz-landing-system : lando
