Because the result is 99% identical to the win64-nsis toolchain, we
produce a single toolchain that can be used both on native windows and
on cross builds.
Differential Revision: https://phabricator.services.mozilla.com/D125926
The build-clang step in the clang-mingw toolchains just replicates what
we already do for clang, except with no patched applied, which could
arguably seen as an issue. Instead of rebuilding what we essentially
already have as a result of the clang-12 toolchain, we use the clang-12
toolchain directly instead.
Differential Revision: https://phabricator.services.mozilla.com/D125912
The reason the error mentioned in build-mingw32-nsis.sh happens is that
the default mode NSIS builds in is a fully-installed mode, where it
hardcodes the locations of its data files. This is why nsis needs to
be used from the same place it's built for. But there's another mode,
enabled with NSIS_CONFIG_CONST_DATA_PATH=no, that makes it relocatable,
and makes it find its data files relatively to the nsis binary.
However, there's a bug in the nsis build scripts, which makes the nsis
binary installed in the destination directory instead of a bin/
subdirectory, while the source code itself looks for data files relative
to the parent directory of the directory that contains the executable.
So we need to set PREFIX_BIN to force the executable to be installed in
a bin/ subdirectory.
There is also an issue in nsis itself when it's executed by anything
other than a shell, which we patch out.
Differential Revision: https://phabricator.services.mozilla.com/D125638
While the comment at the top of build-mingw32-nsis.sh is true, it only
applies to nsis being in the same path in the build tasks as it was
built from in the toolchain task. So we don't actually need to build
it in a mingw32/bin directory, and can ship it in a nsis/bin directory,
as long as that's where we build it.
That makes the toolchain match the expectations from bootstrap, which
also makes PATH adjustments for nsis unnecessary, no other toolchain
used in those builds providing a binary in mingw32/bin.
Differential Revision: https://phabricator.services.mozilla.com/D125637
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
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
This update makes wgpu a vendored dependency instead of having it in gfx/wgpu.
## Notes
It relies on https://phabricator.services.mozilla.com/D123157
It has a quirk related to OpenGL ES backend. Previousy, we manually had to disable GL backend
in order to avoid vendoring WASM dependencies in. This time, manual editing is more complicated,
so instead this change adds a few cargo patch lines to point WASM dependencies to dummy projects.
The update also totally removes SPIRV-Cross, since the latest `wgpu` doesn't depend on it any more.
The compiled binary size for Gecko should improve with this.
Differential Revision: https://phabricator.services.mozilla.com/D123153
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
The wasi-sysroot toolchain contains both a sysroot for wasi and a
compiler-rt for clang. That makes it impractical to use as a
bootstrapped sysroot for wasm32-wasi builds of Spidermonkey.
We thus split the toolchain in two, one for the compiler-rt and one
for the sysroot. Ideally, the compiler-rt one would avoid building
clang/llvm the same way the sysroot one does, but that leads to
a case of chicken-and-egg, because the compiler-rt is needed to build
the clang toolchain. Eventually, the clang build would be split from
the addition of the compiler-rt, but we're not there yet.
Differential Revision: https://phabricator.services.mozilla.com/D122402