--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.
There's nothing that makes sense in the existing setup; we're only not
getting bitten because the set of things that _do_ depend on all of
the flags that differ between the underlying Nightly builds and
single-locale repacks is small, and nobody has complained. For
example, about:licenses probably does not include the Adjust SDK
license for single-locale repacks.
This patch series recompiles the Java code as part of each
single-locale repack, and that means the feature flags, etc, need to
be the same between the underlying compiled code (from the underlying
Nightly build) and the fresh Java compile. This patch tries to
harmonize the two.
MozReview-Commit-ID: 230q7HuD1vV
--HG--
extra : rebase_source : 1be8a389ed289c788add4d3e95c540f29165cf6b
extra : source : d7f794ec69ccd38d66ec5394fac7cc6658e29ce4
There's nothing that makes sense in the existing setup; we're only not
getting bitten because the set of things that _do_ depend on all of
the flags that differ between the underlying Nightly builds and
single-locale repacks is small, and nobody has complained. For
example, about:licenses probably does not include the Adjust SDK
license for single-locale repacks.
This patch series recompiles the Java code as part of each
single-locale repack, and that means the feature flags, etc, need to
be the same between the underlying compiled code (from the underlying
Nightly build) and the fresh Java compile. This patch tries to
harmonize the two.
MozReview-Commit-ID: 230q7HuD1vV
--HG--
extra : rebase_source : 40bdac7073614fcb366e97b733ad98afb4f2dfb4
extra : source : d7f794ec69ccd38d66ec5394fac7cc6658e29ce4
This also turns the tier 2 job B(n)g into tier 1, since moz.build is
still tier 1. It also pushes a lot of GeckoView related tasks into
the main builds, since they should run as part of Gradle builds.
This also removes unused tooltool manifests; the jobs that used these
manifests use only toolchain tasks now.
MozReview-Commit-ID: 2GmnJ7joCTT
--HG--
extra : rebase_source : 75cd2dfb51e0e1b510f5e618c2dc881cf5f22bf2
extra : source : 6b95b09d6afbb83ba89c47b237dfce6e15587bbe
LLVM_CONFIG is only allowed when building stylo. If not building it, it causes invalid option error.
mozconfigs doesn't have same value for milestone.is_nightly of moz.configure.
So, to detect nightly version, I analyze milestone.txt.
MozReview-Commit-ID: Iq1FvxymKEc
--HG--
extra : rebase_source : e07aaf1ee82e7459d97e6558f95967ac7972af9f
- Building is nightly channel only. Beta and release for Fennec 58 don't build
stylo. It means that the package size for 58 beta/release isn't incremented
by this change.
- The preference for stylo is still turned off Nightly 58. It will be turned on
59 after fixing some bugs for crashtests and etc. Our target to enable stylo
for Android is 59.
- ./mach bootstrap already installs clang etc to build stylo and bindgen.
Developers for mobile won't require additional build options for this change.
MozReview-Commit-ID: CIpYl8I5d7x
--HG--
extra : rebase_source : 6387704e4a94db080d4add10298cf1cc254ddec0
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
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
The goal of this approach is to tell Gradle to not connect (or allow
it to connect) to the network when fetching dependencies. No Android
automation tasks should fetch from the network, except the toolchain
tasks (which are specially intended to do so).
It's difficult to arrange this without including the `--offline` flag
everywhere. It _should_ be possible to set offline using an
environment variable -- which would allow us to get rid of these
dotgradle-* files -- but offline isn't an option in
https://docs.gradle.org/4.2.1/userguide/build_environment.html#sec:gradle_configuration_properties
(and certainly not in earlier versions either). Therefore,
environment variable that points to an init.gradle file in automation.
Before this patch, the files telling Gradle whether to start offline
were fetched from tooltool. That's just a layer that doesn't need to
be there.
None of this impacts local developers.
MozReview-Commit-ID: LAXktbBu1Az
--HG--
extra : rebase_source : d23801643d32135a87d410bf5e8508da556ef9be
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
gcc 4.9 is the last version in Android NDK and our minimum requirement of gcc is 4.9+. --with-android-gnu-compiler-version is unnecessary option because gcc version of Android is always 4.9.
MozReview-Commit-ID: 1sutqlvbQU5
--HG--
extra : rebase_source : 77e42aba81da5276bcddd945ea41895ce2461afa
libstdc++ support is broken after moving to moz.configure. No one uses this option and NDK will remove GCC, so we should remove this and --with-android-cxx-stl option.
MozReview-Commit-ID: 3mqyHoRCE00
--HG--
extra : rebase_source : 35aa911a69e159e67f624ab5ab9aea8af4c5342f
Now that we have a Docker image with newer library versions on it, we
can move our builds over. The new images differ from the old
CentOS-based images in two important ways, though:
1) The system compilers in the new image are new enough to be used as
host compilers; additionally, our CentOS-built GCC compilers will not
work. We need to change the Android mozconfigs to reflect that. We
also need to change the Android tasks to not depend on the GCC
toolchain builds.
2) In a similar fashion, we can use the system JDK; we no longer need to
use the JDK from the Android NDK, which we had packaged up via the
Android dependencies task.
Both of these changes come with caveats: our l10n repack jobs continue
to run on the CentOS-based images; l10n repacks have not been completely
converted to Taskcluster. So we need to:
1) Retain the use of our custom GCC toolchain for HOST_CC/HOST_CXX on
the CentOS-based images.
2) Retain the JDK packages in the tooltool manifests, and referencing
them when we build on the CentOS-based images.
CLOSED TREE
--HG--
extra : amend_source : 84120d6bacb5d72a9fbe41e4c3b405d63825da7c
extra : histedit_source : 8320c2193761b745f10850055ee74a3c9ac73615%2Cfbc2a28d8c5004a53305ef858ca5aea4245691e0
Now that we have a Docker image with newer library versions on it, we
can move our builds over. The new images differ from the old
CentOS-based images in two important ways, though:
1) The system compilers in the new image are new enough to be used as
host compilers; additionally, our CentOS-built GCC compilers will not
work. We need to change the Android mozconfigs to reflect that. We
also need to change the Android tasks to not depend on the GCC
toolchain builds.
2) In a similar fashion, we can use the system JDK; we no longer need to
use the JDK from the Android NDK, which we had packaged up via the
Android dependencies task.
Both of these changes come with caveats: our l10n repack jobs continue
to run on the CentOS-based images; l10n repacks have not been completely
converted to Taskcluster. So we need to:
1) Retain the use of our custom GCC toolchain for HOST_CC/HOST_CXX on
the CentOS-based images.
2) Retain the JDK packages in the tooltool manifests, and referencing
them when we build on the CentOS-based images.
Update the host jsshell, which is used for minifying Fennec JS code, to
the one from the 56 release, so minification works again.
MozReview-Commit-ID: K87XQrAbC9p
--HG--
extra : rebase_source : 9ae4aad02ca11bdde0d2da9f0bb98fb5e83769d1
Using /home/worker is the build directory has a 30% talos performance
loss, because test machines has a /home mount directory.
MozReview-Commit-ID: 554IPMRWgzK
--HG--
extra : rebase_source : 00827d3f6bd705419bc801eb05b543af1ddc274f
This change makes us upload an `$(PKG_BASENAME).generated-files.tar.gz` archive
alongside other build artifacts which contains all the generated source files
from the build. A change after this will introduce an `upload-generated-sources`
task to take this artifact and upload the individual files to an S3 bucket.
This will be used to provide links to generated source files when they appear
in stack traces in crash reports.
MozReview-Commit-ID: 6yQAdlZ5q3O
--HG--
extra : rebase_source : d92fb17ae737d1360e9724997f6688e29bedef12
extra : source : 14d18d7cf454c4c3d0f6d49d1d01660e06e4be4b
I took the time to change jcentral (which is just wrong) to jcenter,
which is the tag used in the nexus.xml.
Order matters! Gradle resolves dependencies in the order given. That
is, jcenter is preferred to google.
MozReview-Commit-ID: CcWBukhiHa4
--HG--
extra : rebase_source : 73a3b3f013d9154ff3f5732593ba9fbe2b75d1f0
Before this patch, we used the Gradle sdk-manager-plugin to download
and install Android SDKs and other dependencies. This plugin is now
deprecated; the main dependency downloading functionality has been
incorporated into the Android-Gradle build plugin. Unfortunately,
it's been incorporated into newer versions that in turn require newer
toolchains than we currently support, so we can't use the new
functionality immediately.
Rather than replace sdk-manager-plugin with equivalent Gradle-based
functionality, this ticket uses recently added bootstrap functionality
to bootstrap the Android SDK during the dependencies task. It then
_uses_ that SDK to run the dependency fetching task, _produces_ an
android-sdk-linux.tar.xz, and then _uploads_ the new artifact as a
private artifact, ready to be pushed into tooltool. This avoids
engineers building this critical part of the toolchain locally
themselves, and will also feed into ongoing work to push toolchain
artifacts into build jobs in Task Cluster.
MozReview-Commit-ID: B6FC0ugaCef
--HG--
extra : rebase_source : 782719438a464b8021db58be398be9d5afb3b543
I'm confident nobody is configuring this locally, so there's no reason
to keep the existing name (and grow the new semantics) nor to
deprecate the existing name explicitly.
MozReview-Commit-ID: HW3epgwZFpO
--HG--
extra : rebase_source : d328f9ce9299dcd80e508925314236747aee1ea3
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
