This requires unlocking the unstable features in the rust compiler
by using RUSTC_BOOTSTRAP=1
MozReview-Commit-ID: 1uUG1Ekp1YH
--HG--
extra : rebase_source : d8a5aa5d13f3ee055de8a544b0d5ca8af0aab751
As of bug 1430036 it was only set when building on CentOS, and as of bug
1432398, we don't have CentOS-based docker images anymore.
--HG--
extra : rebase_source : 5ade9bee773bca3283cfdb9d69209033fe82253f
The binutils we currently use as part of our GCC toolchain artifact
doesn't understand some relocations in the CRT objects on Debian
stretch, making the embedded CRT objects from bug 1427344, which we want
to remove in bug 1431251, necessary.
OTOH, there is no benefit from using our GCC toolchain artifact for host
compilations on those builds. In fact, Android builds, which are in a
similar position, being built on Debian stretch and being cross-builds,
don't care to use our GCC toolchain artifact.
It's arguably a good thing that those builds are not tied to the version
of GCC we use to build Firefox for linux, so let's remove this
dependency.
--HG--
extra : rebase_source : a80d4e4fb01a4862b844ebde0c521a635f462c0a
moz.configure automatically enables profiling if the milestone is
Nightly (see js/moz.configure:226). So, --enable-profiling in the
nightly mozconfigs is redundant and can be removed.
The whitelist has also been updated to reflect the removal of this
line.
MozReview-Commit-ID: 7nUJVcFOp6c
--HG--
extra : rebase_source : 86db8c2bf646c83701ade8c4a10d667d1c2da6f1
mk_add_options has this kind of awkward feature where
mk_add_options VAR=value
would set VAR for the build through client.mk, but not when running
make -C objdir target. But
mk_add_options "export VAR=value"
does.
We might want to change that on the long run, but the side effects would
have to be calculated first.
OTOH, we have automation jobs that run compilations during `make check`
(e.g. rusttests), which is not invoked through client.mk. So they
currently don't get the same PATH as the build part, meaning that
they're using system binutils instead of the one from the GCC toolchain
package.
--HG--
extra : rebase_source : aab7f221243c486cf70c7b0c91b9313231050ed8
OSX (cross) repackages are currently using a tooltool manifest to get
libdmg and hfsplus. Change those jobs to use the toolchain artifacts
instead.
At the same time, modify the repackage mozharness script's _run_tooltool
so that it doesn't fail with MOZ_TOOLCHAINS being set but without a
tooltool_manifest_src, matching the similar function in buildbase.py.
--HG--
extra : rebase_source : d128d4709c5d1d28d1a6b9c585fde82e99f725c7
The reason it was set from mozconfigs is that profiling require it. But
since it was added, bug 751355 made it implied by --enable-profiling,
and bug 1144842 further made sure that profiling and STRIP_FLAGS were
tied together.
--HG--
extra : rebase_source : c2a6b03bf007e661db48e40cca98e81aaa04c878
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 9ac927bb7bd8c057264c8f6f9ca5cbf79a839c4e
It turns out that in all cases it was the last tooltool manifest entry,
so we can remove the tooltool manifests entirely, and remove all
references to them.
--HG--
extra : rebase_source : d8447b5422e63e88444008fddb76d658829694de
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : c7de7b3959a3c6b77ea202d9609c891b5b7ec442
It now only does something trivial, which also happens to be a no-op
because it's the default. It does have a commented entry for possible
gtk+2 builds, but we're soon going to remove that possibility anyways in
bug 1278282.
--HG--
extra : rebase_source : 0de751e523ee002bbe6638d223eb384364edd22b
It turns out that in all cases it was the last tooltool manifest entry,
so we can remove the tooltool manifests entirely, and remove all
references to them.
--HG--
extra : rebase_source : 0aa9ef8151c2fccf62507dfecc0bc57b157772e1
Now that build environment docker images have gtk+3 installed in
/usr/local, adjust mozconfigs to point pkg-config there, and remove
all the glue that was required to build using the tooltool package.
Also remove the --x-libraries=/usr/lib on 32-bits builds, which only
confuses the linker.
--HG--
extra : rebase_source : 22b1273ae4b78807b355d33ed5895bdfe83a141d
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
The "contract" for toolchains is that extracting foo.tar.xz creates a
directory named foo/. That is however not true for mingw32.tar.xz, which
extracts into gcc/, possibly overwriting files from the gcc.tar.xz
archive (which is also used for mingw builds, for the host part).
This is also not true for nsis.tar.xz, but it reportedly has problems
when it's not in the same directory as mingw32.
But mingw32 doesn't actually need to be mixed with gcc, so it's better
to separate them as they are supposed to be.
--HG--
extra : rebase_source : 30d90af64459bbb31bc076e48f3c661fa9cd4a79
With all of our builds in Taskcluster now, we should never be uploading
symbols from build tasks. Unfortunately Windows builds were still doing so.
This patch removes MOZ_AUTOMATION_UPLOAD_SYMBOLS from all the in-tree
mozconfigs and a few other places so that it should always default off
(per moz-automation.mk). The rest of the uploadsymbols bits will be
removed once Thunderbird fixes their automation.
This patch was mostly autogenerated by running:
rg --files-with-matches UPLOAD_SYMBOLS browser/config/mozconfigs/ mobile/android/config/mozconfigs/ | xargs sed -ri '/.*UPLOAD_SYMBOLS.*/d'
sed -ri '/.*UPLOAD_SYMBOLS.*/d' build/unix/mozconfig.linux build/mozconfig.win-common build/macosx/local-mozconfig.common build/mozconfig.automation
Then mobile/android/config/mozconfigs/common and
taskcluster/scripts/builder/build-linux.sh were hand-edited.
MozReview-Commit-ID: Cy8kSEodSg4
--HG--
extra : rebase_source : 01caf1651b4eb428313e1f371aa585f8f34c4151
exe_7z_archive.py runs during the MinGW build L10N check step, and
hardcodes 7z as the 7zip executable. This works on Windows, but not
Linux. We need to pass it the correct executable for 7zip, which is
located during configure.
However, repacks (repackage-winXX-nightly) don't do configure, and
don't have the tools to do configure. So we leave the default
command in the python script if one is not supplied.
MozReview-Commit-ID: B7GEKRYEJTD
--HG--
extra : rebase_source : 10ec7e688d53341625217306e88f2e647195ce8d
None of these are defined in any "nightly" mozconfigs.
Some of these lines may occur and be set by mozconfigs. But the
entire premise of compare-mozconfigs is flawed because it only compares
file content: not the end result of mozconfig evaluation. (mozconfigs
are shell scripts and a lot of logic occurs in other sourced shell
scripts.)
MozReview-Commit-ID: 2Nwo3ePJreb
--HG--
extra : rebase_source : 4fef846c6e501cef29ca9bca573f376e9ac2f97c
This variable isn't consumed anywhere. I have no clue where it
was consumed. It appears to be the product of an old era.
MozReview-Commit-ID: 6iRdLW89ZjW
--HG--
extra : rebase_source : d338287d78462a78cf70671b00d7cf1fd9520785
extra : source : aa0428bd81463d7e12454238681f27085678c92a
There are no other references to PROFILE_GEN_SCRIPT outside
of the mozconfig whitelist file. The deleted entries from the
whitelist file were meaningless.
MozReview-Commit-ID: IhOV8Hlfmhl
--HG--
extra : rebase_source : e118008a8a87c83e6e025eca9e7ce51ce8fce0a3
extra : source : 5280a8429e4174e1cb1e0dd4c5e34e9fe539b171
We no longer define MOZ_MAKE_FLAGS in the in-repo mozconfigs. Nor do we
pass MOZ_MAKE_FLAGS from any automation configs as far as I can tell.
MozReview-Commit-ID: LYU1dI44uhX
--HG--
extra : rebase_source : 08a9e7801ae619ba1cd36f6c262c29a4735035d0
extra : intermediate-source : 8430d8501abcd30d15e0ef73d9bfa64d6ede8697
extra : source : 3f151657ee8d7a5a87629826f654ee5c807b5346
--enable-elf-hack is the default on all platforms where it's supported,
and is completely ignored on platforms where it's not supported.
While moving the flag to moz.configure, we're going to make it only
work on platforms where elfhack is supported, so we at least need to
remove it from mozconfigs for those platforms where it's not supported.
But generally speaking, we want less things in mozconfigs, so just
remove it from there, since it's the default anyways.
With that fixed, Re-enable MOZ_AUTOMATION_L10N_CHECK for MinGW
MozReview-Commit-ID: BDTtY1J7sBj
--HG--
extra : rebase_source : 162267bf08a6e477af3b8b119a9ef9df65ba8267
This line was added to the nightly macosx64 mozconfig in 9312a1903bf4
(bug 1391643). But we didn't catch it because compare-mozconfigs
only analyzes the current platform and we cross compile for MacOS
from Linux.
MozReview-Commit-ID: 35Q2c0mybPi
--HG--
extra : rebase_source : 25707037ca07ec22de283abcfe96c4faea71d55e
The mechanism by which PGO builds are kicked off is kinda wonky.
The MOZ_PGO environment variable is recognized by configure and setting
it will result in MOZ_PGO being defined in substs. In addition, the
build backend (previously client.mk, now Makefile.in) also recognizes
MOZ_PGO (from mozconfig or environment) and takes appropriate action.
In-tree mozconfigs set MOZ_PGO via mk_add_options. mk_add_options
is intended as a mechanism to inject state into client.mk and the
make-based build system.
In addition, there is code in mozharness (unchanged by this commit)
that sets MOZ_PGO if appropriate.
A PGO build configuration is different from a non-PGO build
configuration. Therefore a make-centric environment variable to
control PGO is not ideal. Instead, this should be defined as a
configure-time flag and the build invocation should key off that.
This commit normalizes in-tree mozconfigs to set MOZ_PGO via
ac_add_options and updates the PGO documentation to recommend
this method.
MozReview-Commit-ID: k6AZyJuXjs
--HG--
extra : rebase_source : b1a6348611eba08dd67ec938cca5586fbe8e6910
extra : source : 25c7ebc7c44dd253f421b6de3d0337635d0c99d0
The new VS package is now based on update 15.4.2, although that release didn't affect any files in our package. I'm picking up the update mostly just to make filename unique.
This also enables the crash reporter on the MinGW build, as this is the
only thing blocking that from working.
MozReview-Commit-ID: Hygd7UUQvwl
--HG--
extra : rebase_source : a4a12b8edaa5b1fba869d6f7c21fc8444be2d9d7
Repack of the new Visual Studio release using the packaging
scripts from bug 1407678. This version also includes the
pgo runtime, resolving a performance regression from the
previous package.
MozReview-Commit-ID: LhoVyG4IwmP
--HG--
extra : rebase_source : 0d3d2f28f05335976d236e5f76893307c252dc96
Repack of Visual Studio 2017 15.4.0 with SDK 10.0.16299.0
created by David Major by running the installer on a fresh
VM and then running the updated packaging script from
bug 1407678.
MozReview-Commit-ID: 7ZKoA6ncOPr
--HG--
extra : rebase_source : dcb72a71f34ada6ead631fe8fac0b31f0ddb8e29
We need mozharness configurations and mozconfigs for rusttests. We are
explicitly not doing Windows debug configurations currently because of
peculiar link errors in such configurations.
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
Asking for a build peer review and a releng review. The releng one is mostly on if this would break merge day scripts.
MozReview-Commit-ID: EXpRgHQKK4e
--HG--
extra : rebase_source : a534d2ed62d1400d39050d3430c407792266707d
A followup change will be adding a new automation step that wants to be skipped
in artifact builds, and this will make that simpler.
MozReview-Commit-ID: 5xwRB9eCRQn
--HG--
extra : rebase_source : 2fccd9d128ab92c98515762a62a0a2e89bf9ca24
extra : source : a02695cbf5762eb0eb7087239319807eb447ca1e
A followup change will be adding a new automation step that wants to be skipped
in artifact builds, and this will make that simpler.
MozReview-Commit-ID: 5xwRB9eCRQn
--HG--
extra : rebase_source : 0b5b5087eddbf030161482f054ddd4d7cc08ffd4
Ryan VanderMeulen
ffxbld
Kim Moir
Tom Ritter
Andreea Pavel
Jesse Schwartzentruber
Kartikaya Gupta
Mike Hommey
Marco Castelluccio
Simon Fraser
Gregory Szorc
Coroiu Cristina
Steve Fink
Ian Moody
Ted Mielczarek
David Major
Sylvestre Ledru
Dorel Luca
Sebastian Hengst
Cosmin Sabou
Bill McCloskey
Ralph Giles
Chris AtLee
Nathan Froyd
Christian Holler
Ted Mielczarek
Andrei Obreja
Chris Manchester
J. Ryan Stinnett
Justin Wood
Nick Thomas
Wes Kocher