We need to install a new enough binutils for both of these jobs and
ensure that it's properly found on the linux job.
Differential Revision: https://phabricator.services.mozilla.com/D23678
--HG--
extra : moz-landing-system : lando
These builds no longer use gcc, so they no longer need gcc files on PATH
or LD_LIBRARY_PATH.
Differential Revision: https://phabricator.services.mozilla.com/D22712
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
And remove the manual --enable-dmd in in-tree mozconfigs, as well as
--enable-profiling, which is implied by --enable-dmd.
This disables DMD on add-on-devel builds, which don't look like they
were actually meant to have DMD enabled in the first place (they only do
because they use the nightly mozconfig on all branches, and as a matter
of fact, the nightly mozconfig didn't enable DMD before bug 1409739)
This enables DMD on mingw builds with the same conditions applied as
other platforms, meaning that it's not enabled on opt builds on release
branches.
And this enables DMD on plain builds, which, from this perspective,
reflect local developer builds, and this is the expected effect.
Depends on D21161
Differential Revision: https://phabricator.services.mozilla.com/D21162
--HG--
extra : moz-landing-system : lando
Builds that should have jemalloc enabled already have it enabled by
default. An explicit --enable-jemalloc is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D20273
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
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
In Bug 1522354, the default for `--host` was changed to detect running on a 64bit host. Since `--target`
defaults to `--host`, this changed the default for `--target` as well. This didn't affect builds, as they
explictly set the `--target` in `build/win32/mozconfig.vs2017`. Set it explicitly in L10n builds as well.
This patch also fixes devedition
Differential Revision: https://phabricator.services.mozilla.com/D18276
--HG--
extra : moz-landing-system : lando
Like bug 1505072 did on other platforms. The rust tests don't go through
the whole build system, and even when the clang plugin is enabled, they
don't build it. So when passing compiler flags down through cargo, the
arguments enabling the plugin are passed, and compilation of C/C++ code
from cargo subsequently fails.
Differential Revision: https://phabricator.services.mozilla.com/D18178
--HG--
extra : moz-landing-system : lando
In Bug 1522354, the default for `--host` was changed to detect running on a 64bit host.
Since `--target` defaults to `--host`, this changed the default for `--target`
as well. This didn't affect builds, as they explictly set the `--target` in
`build/win32/mozconfig.vs2017`. Set it explicitly in L10n builds as well.
Differential Revision: https://phabricator.services.mozilla.com/D17967
--HG--
extra : rebase_source : 80bd3609ae29be0748d56be407c4d95443e256a0
extra : amend_source : c56db8fe0f680d0b4f9f14e24269799c76646203
It turns out, we don't need to `mk_add_options export` the variables
from the in-tree mozconfigs. If anything, that causes problems when
trying to simplify the mozconfigs, because it makes the variables
exported from .mozconfig.mk, overriding what configure may change and
store in autoconf.mk.
All the variables are handled by configure in a way that makes them
available in autoconf.mk, so there's no loss there, and with the
python/shell-based mozconfig loader, it turns out we don't need to go
through extra normalization via cmd.
autospider.py, being its own pseudo-mozconfig parser, still does need
it, though, but it was hooking into it already, so just inline that.
Differential Revision: https://phabricator.services.mozilla.com/D17769
--HG--
extra : moz-landing-system : lando
Our normal Windows nightlies get LTO enabled implicitly by the PGO logic, but since we don't have arm64 PGO builds, let's enable LTO explicitly there.
Differential Revision: https://phabricator.services.mozilla.com/D17418
--HG--
extra : moz-landing-system : lando
Jesse Schwartzentruber
ffxbld
Nathan Froyd
Mike Hommey
Tom Prince
Sylvestre Ledru
Bogdan Tara
Mihai Tabara
Brindusan Cristian
Ciure Andrei
Thomas Daede
Marco Castelluccio
Geoff Brown
Justin Wood
Sebastian Hengst
Razvan Maries
Ryan VanderMeulen
David Major