- Because we don't have a native arm64 mac one, alias the x86_64 one.
- Because we always compress with zstd, don't pretend the main script
has any power on the compression (which was wrong for Windows).
Differential Revision: https://phabricator.services.mozilla.com/D149204
There are a set of problems that arise from that setup that need to be
addressed before this can be enabled, but upstream is toying with it,
and it's better to have a setup that is stable rather than a setup that
can break when upstream changes something (which happened again earlier
today).
Differential Revision: https://phabricator.services.mozilla.com/D148625
Building libc++ and libc++abi standalone is not supported as of LLVM 15
(it already shows a deprecation warning in LLVM 14). Switch to using the
new canonical way to build them*, and get libunwind along.
As a bonus, merging the libraries is handled by the LLVM build system in
that case.
[*] https://libcxx.llvm.org/BuildingLibcxx.html
Differential Revision: https://phabricator.services.mozilla.com/D145543
The separate libunwind we were getting is from an old llvm mirror. We
can just use the version from llvm-project, which will be up-to-date,
and will allow to simplify the whole process later.
Differential Revision: https://phabricator.services.mozilla.com/D145542
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
We were getting ('dav1d', '87f9a81cd770e49394a45deca7a3df41243de00b', '')
which is three values and throwing an exception.
Differential Revision: https://phabricator.services.mozilla.com/D143060
Its layout differs from the one in the tooltool archive for forward
compatibility with the upcoming (clang 15) -winsysroot flag.
There is probably more filtering we can do to somehow match what
windows_toolchain.py used to do, but we'll keep that for later.
Differential Revision: https://phabricator.services.mozilla.com/D143126
Its layout differs from the one in the tooltool archive for forward
compatibility with the upcoming (clang 15) -winsysroot flag.
There is probably more filtering we can do to somehow match what
windows_toolchain.py used to do, but we'll keep that for later.
Differential Revision: https://phabricator.services.mozilla.com/D143126
The llvm-symbolizer tasks currently extract a llvm-symbolizer from clang
tasks. Changes in clang 14 make the hack that we have in place to keep
llvm-symbolizer statically linked to libllvm while clang uses a dynamic
libllvm not work anymore, so it's time to bite the bullet and build
llvm-symbolizer separately.
We share most of the build setup with the compiler-rt build.
Differential Revision: https://phabricator.services.mozilla.com/D140711
The toolchain file is a helper for cross-compilation that even deals
with case-sensivity in MSVC, which simplifies our setup.
Differential Revision: https://phabricator.services.mozilla.com/D140710
