This uses a patched version of glutin 0.28 which builds successfully
on Android. It has the caveat that the application is now responsible
to ensure we only create a GL context when the application has been
resumed and the window is valid. This patch does so by spinning an
event loop on startup until we receive a Resume event. This is a bit
of a hack, and will break if the app is minimised, but it is good
enough for wrench's use case.
Cargo-apk no longer supports specifying a separate target_sdk_version
and android_version, meaning we must use a target_sdk_version of
31. This means we no longer have permission to read from "/sdcard", so
wrench and its scripts have been updated to use the application's
"external data dir".
Finally, when running on CI we use a patched version of cargo-apk
which allows building with SDK version 31 and NDK r21d. We should be
able to switch to the upstream git version once we update to NDK r23.
Differential Revision: https://phabricator.services.mozilla.com/D144418
This improves out-of-the-box support for cross-compiles on tier-1 build
platforms, including for asan. This also reduces the number of different
*-cross toolchains we need for CI builds.
The linux clang is now also a repack, like the others, and the insertion
of the wasm compiler-rt is moved to the repack, which also allows to
remove that part of the build-clang.py script.
Differential Revision: https://phabricator.services.mozilla.com/D138749
This improves out-of-the-box support for cross-compiles on tier-1 build
platforms, including for asan. This also reduces the number of different
*-cross toolchains we need for CI builds.
The linux clang is now also a repack, like the others, and the insertion
of the wasm compiler-rt is moved to the repack, which also allows to
remove that part of the build-clang.py script.
Differential Revision: https://phabricator.services.mozilla.com/D138749
For a long time two copies of the 'taskgraph' module have existed in parallel.
We've attempted to keep them in sync, but over time they have diverged and the
maintenance burden has increased.
In order to reduce this burden, we'd like to re-join the two code bases. The
canonical repo will be the one that lives outside of mozilla-central, and this
module will depend on it. Since they both have the same module name (taskgraph)
we need to rename the version in mozilla-central to avoid collisions.
Other consumers of 'taskgraph' (like mobile repos) have standardized on
'<project>_taskgraph' as their module names. So replicating that here as well.
Differential Revision: https://phabricator.services.mozilla.com/D127118
It made sense when we did have problems with the one shipped with clang
and needed an explicitly newer version, but that hasn't been true in a
while. On the contrary, we're now using a version older than clang for
no reason other than having forgotten to update it.
Differential Revision: https://phabricator.services.mozilla.com/D124886
There are two big parts in the MSVC toolchain we use:
- the Windows 10 SDK
- Visual C++
For the former, both the 15.8.4 and 15.9.6 toolchains are using the same
version of the Win10 SDK.
For the latter, we're not using the compiler itself anymore, so the only
substantial difference is in the headers and libraries included with
Visual C++, as well as the redist libraries for the CRT. Both versions
are supposed to be compatible to the same set of OS versions, fitting
our system requirements.
This makes us use the same version of MSVC on all our Windows builds
(arm64 builds were already on 15.9.6).
Differential Revision: https://phabricator.services.mozilla.com/D123720
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369