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
Since the buildbot-based Windows builds using releng.manifest are busted
anyways, there is no reason to keep clang entries in there. Which makes
those manifests identical to clang.manifest, so remote the latter.
--HG--
extra : rebase_source : eef7eca4bafc4e348eadc04d6da2bd17ea20deea
Bug 1374748 removed Stylo-specific builds, but there are still a few config
files left behind that are now unused. This cleans them up.
MozReview-Commit-ID: EAUx7YKQBmN
--HG--
extra : rebase_source : 7e2124f7e5625d25efc5e868e151dbdc02cfba65
Bump the minimum required version of the Rust toolchain to
the current stable release so we can take advantage of new
features.
Highlights of the 1.19.0 release:
* C-compatible `union` (untagged enums).
* Support for Visual Studio 2017.
* Non-capturing closures can be coerced to `fn` bindings.
* Numeric field names in tuple struct initializers.
* Higher macro recursion limit.
* `break` can return a value from `loop` expressions.
* Better error handling with mis-configured Visual Studio environments.
This change also enables 1.18.0 features. Some highlights:
* `pub(mod)` &c. for better control of symbol visibility.
* struct packing for better memory footprint in generated code.
* Faster build times.
MozReview-Commit-ID: 2OpUjAcytpE
--HG--
extra : rebase_source : 2ed0d7c4e7b78c26f7a7476e7b284bf1bdbe7c8b
Build Stylo (the styling system from servo) by default in all
builds for win32, win64, macOS and linux64 targets. It was
previously enabled for automation builds, so this just changes
the behaviour for local developer builds.
Note that this introduces a new dependency on libclang for the
binding generator. If you're developing on a tier-1 platform,
run `./mach boostrap` to install a working copy. Otherwise
llvm+libclang 4.0.1 is recommended.
Remove the explicit --enable-stylo=build in mozconfig.stylo
in favour of the configure default.
Add mozconfig.stylo to the hazard and debug-asan mozconfigs
so LLVM_CONFIG is defined properly for those builds.
Based on a patch by Bobby Holly in bug 1356991.
MozReview-Commit-ID: C2wRNl7JHpz
--HG--
extra : rebase_source : 1ed7c36a64e25b235a26864592cd7ea969a4cd25
The manifest is only used for windows clang-cl toolchain jobs, and
building clang-cl doesn't use make or rustc.
--HG--
extra : rebase_source : 2209098306461cac9c2145d8d9a0f2ea096b1f08
Except for fuzzing and linux static analysis. Also, we leave them in windows
releng.manifest in case buildbot builds still need to happen for some reason.
--HG--
extra : rebase_source : 43299b3aca8a84ccca5adb3b03c9ca9d500adcb5
Missed this in the update in bug 1382743. Thanks to glandium
for pointing out the oversight.
MozReview-Commit-ID: 6P4qnBCNEGy
--HG--
extra : rebase_source : d4b540d27ffaaa2edf5554a641dfc99fc93e9b92
We want most builds to be actually using sccache, so we include
mozconfig.cache from mozconfig.common. However, since the --with-ccache
configure option doesn't exist on non-compile jobs (e.g. artifact
builds), we move to using the CCACHE environment variable instead, which
allows us to unset it in mozconfig.no-compile.
And since mozconfig.no-compile is always included where no_sccache is
set, we can remove that variable.
--HG--
extra : rebase_source : a8c743de1fd7a3c0fbc53f7c233df36585897767
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
New upstream stable release.
Unions (untagged enums) for (unsafe) interoperability with C.
The `break` keyword can yield an expression value from a `loop`.
Non-capturing closures coerce to function pointers.
Numeric initializers for tuple structs.
MozReview-Commit-ID: 6TMjzXZuBKg
--HG--
extra : rebase_source : 3596ad4a1a1e299a4520fe064389912aeb986968
LLVM_CONFIG, per the contents of toolkit/moz.configure, is tied to
--enable-stylo, but it currently is set on all types of builds. It
currently happens to work, but it's actually not meant to, and sure
enough, the fix for bug 1374727 exacerbates that.
So we create a new mozconfig.stylo file that enables stylo and sets
LLVM_CONFIG, such that only build types that do enable stylo have
LLVM_CONFIG set.
--HG--
extra : rebase_source : 01277a79951888046c0b8e29c61cfc3b049ee0f0
This adds the mozconfigs, mozharness configs and taskcluster changes required
to create optimized DMD builds for linux64, win32, win64 and macosx64.
These builds will happen nightly on mozilla-central
We also add support for custom build variants on Windows (or other generic
worker environments).
MozReview-Commit-ID: HrVT9PLSWVx
--HG--
extra : rebase_source : 39ac752a312afe04187728da82a4a7f722634811
We just did the same for Linux64. Windows CI for this configuration
appears to be happy. So let's do it.
MozReview-Commit-ID: 9MmT2jzNGhQ
--HG--
extra : rebase_source : cb2edf5ffcef5aa1937ff002a5b6f843e877b575
This patch enables talos test suites to run on VM (taskcluster) and also enables these test suites to run with GCOV code coverage instrumentation on the linux64-ccov build.
MozReview-Commit-ID: 7p59zvra1ge
--HG--
extra : rebase_source : 990ebecb9daaee7c5030e08b0d763493103f0fe8
As of bug 1373150, l10n repacks do not require a anything to compile, so
they can stop downloading most toolchains from tooltool. However some
tools are still required, such as mozmake on Windows and DMG-related
tools on cross OSX.
--HG--
extra : rebase_source : f46e851c7941491530ce65490d0cfce4f9f02e35
Before bug 1373150, the l10n mozconfigs would include
compilation-related mozconfigs, which include setting compiler paths,
and setting --target for cross builds. After bug 1373150, the
compilation-related mozconfigs are not included anymore, which made
--target unset for l10n builds, leaving it to configure to guess what it
is based on the host. Which for cross builds is Linux, so configure
would set things up for a linux build, which doesn't work to do osx
l10n repacks.
So we add back an explicit --target to those mozconfigs, without
including all the compilation-related things.
We set the target to x86_64-apple-darwin, which is the same as what was
set through build/macosx/cross-mozconfig.common. This is different from
what the native osx builds would get (x86_64-apple-darwin11.2.0), but
the extra version in that target is actually not relevant and native
builds shouldn't care that it's gone.
Before bug 1373150, the l10n mozconfigs would include
compilation-related mozconfigs, which include setting compiler paths,
and setting --target for cross builds. After bug 1373150, the
compilation-related mozconfigs are not included anymore, which made
--target unset for l10n builds, leaving it to configure to guess what it
is based on the host. Which for cross builds is Linux, so configure
would set things up for a linux build, which doesn't work to do osx
l10n repacks.
So we add back an explicit --target to those mozconfigs, without
including all the compilation-related things.
We set the target to x86_64-apple-darwin, which is the same as what was
set through build/macosx/cross-mozconfig.common. This is different from
what the native osx builds would get (x86_64-apple-darwin11.2.0), but
the extra version in that target is actually not relevant and native
builds shouldn't care that it's gone.
--HG--
extra : rebase_source : 79d1616f0cc8291fbc3432165891fdfe8f221f95
The in-tree mozconfigs for Linux64 have been updated to build
Stylo by default. Stylo is still disabled in builds.
The existing Stylo Linux64 platform still exists. It still
uses its own mozconfigs. These mozconfigs source the mozconfigs
changed in this commit. This results in both --enable-stylo=build
and --enable-stylo being passed to configure. The latter takes
precedence.
This commit stops short of implying --enable-stylo=build as
the configure default for Linux64. I'm not sure if we're ready
to make that leap just yet.
MozReview-Commit-ID: K8rafDMlAGu
--HG--
extra : rebase_source : 7a3f7b63429bb2db18988478c0f4e7012b5ddee9
extra : source : 471a163b37d092fc5bf7a56bcf5c5295f727b8d8
Reduce development drag by requiring the most-recent-but-one
stable Rust release. This version is packaged for most
distros, but lets us use more recent library and language
features and spend less time finding work-arounds.
MozReview-Commit-ID: 4W3vkjlKoTu
--HG--
extra : rebase_source : 3828a8be964081bedb2857f9f71f4cd99f75c8be
The in-tree mozconfigs for Linux64 have been updated to build
Stylo by default. Stylo is still disabled in builds.
The existing Stylo Linux64 platform still exists. It still
uses its own mozconfigs. These mozconfigs source the mozconfigs
changed in this commit. This results in both --enable-stylo=build
and --enable-stylo being passed to configure. The latter takes
precedence.
This commit stops short of implying --enable-stylo=build as
the configure default for Linux64. I'm not sure if we're ready
to make that leap just yet.
MozReview-Commit-ID: K8rafDMlAGu
--HG--
extra : rebase_source : 5d32735f2574fae3bc9a396a06efa745d8fd1fb7
sccache changes "--showIncludes" to "--show-includes" which clang-cl
doesn't understand. According to the owner's comment, this is because
it doesn't actually support clang-cl, disable it for now.
MozReview-Commit-ID: 3uK0CF9Tgyv
--HG--
extra : rebase_source : dabef27962fb3406e2c1f3c29aa6fe9c0174e2e5
We updated win64 builders to rust 1.18 while it was still in
beta to pick up better crash reporting. Bump those builds to
the stable toolchain now that it's released.
MozReview-Commit-ID: 1LlmrDfLfWL
--HG--
extra : rebase_source : 4c14198cf962db26a072cd4b6316edbe870cf5bd
A number of developers find it convenient to build with
--disable-optimize --enable-debug for an improved debugging experience.
We don't currently have a configuration in CI that ensures this
combination of options works, so various changes break builds with this
configuration every so often. We should test such configurations to
ensure they build to provide a smooth experience for developers.
Update official builds for 64-bit Windows to use
1.18.0-beta.4 (0308c9865 2017-05-27). This picks
up a fix to unwinding with panic=abort which gives
us better crash reporting on that platform.
MozReview-Commit-ID: HLZSixr8Sxe
For a long time, we've kind of forced the GCC version used to compile
Firefox on automation to the minimum version we do support, because
using a newer version would pretty much guarantee that builds with older
versions would break.
Ideally, the same would be true of rust, but it's not the case, and sure
enough, building with older versions breaks. The most recent example is
bug 1367734 making rustc 1.17.0 required but leaving configure checking
for version 1.15.1.
There are multiple reasons why we'd want to use newer versions of rust
to build shipping versions of Firefox other than language requirements,
but we should still ensure building with supported versions of rust
doesn't break silently.
Here we add a set of new linux jobs that build opt and debug build with
the baseline of supported toolchains. At the moment, that's GCC 4.9,
rust 1.15.1, and clang 3.9 (for bindgen). That's a copy of the current
toolchains used for normal linux jobs, with rustc downgraded to the
package used after bug 1338311.
Further down the line, we'll be able to bump the versions of GCC, rust
and/or clang for the shipped Firefox builds, while keeping those jobs on
GCC 4.9, rust 1.15.1 and clang 3.9, until we do intentionally want to
bump those versions (as well as the corresponding configure checks).
--HG--
rename : browser/config/tooltool-manifests/linux64/releng.manifest => browser/config/tooltool-manifests/linux64/base-toolchains.manifest
extra : rebase_source : 33f609f44c1e70cf970ec8af328e0408e01ec0d2
As of bug 1342503 being fixed, all of our desktop firefox builds have
webrender compiled in by default. Webrender can therefore be enabled at
runtime either by a pref or environment variable on any desktop firefox
build. The old builds that we originally used to stand up webrender are
no longer needed, as the *only* difference between them and the regular
builds are that they build with the pref turned on instead of turned
off. This doesn't warrant keeping around these extra builds, and this
patch removes them along with all the associated goop that was needed to
configure them.
MozReview-Commit-ID: 5wlOWo11fEk
--HG--
extra : rebase_source : 696afdd2d9fb5f7932d0737a7d71c3aa6af0bd64
One of the Rust crates that is built as part of geckodriver's dependency
chain uses a build script to compile some C code.
Because mozbuild does not yet pass the compiler wrapper down to where
the gcc crate can find it, we need to avoid building on geckodriver when
this is the case.
When compiling the browser for the rooting hazard analysis build (labelled
H on Treeherder), the MOZ_HAZARD environment variable will be set and
available to moz.build descriptions.
MozReview-Commit-ID: GprFKtvXvOE
--HG--
extra : rebase_source : f45aa5d8c86673c8287371efcfa703755c2b2073