This allows using the build-llvm.sh script for doing a cross build
of LLVM, while the same directory may contain a native build
which can be out of sync with the actual source.
If nothing was built and installed, the installation merging command
fails with an error like this:
cp: cannot stat '/tmp/tmp.OAj9E7UBhI/install/.': No such file or directory
Therefore, skip this step if nothing really was built and installed.
The main changes for mingw targets since 18.x is primarily
minor bug fixes. llvm-dlltool has also been improved to handle
cases of renamed imports, where the target of the rename doesn't
exist as a normal import.
These days, it seems to be installed out of the box already on the
runner images, and installing it triggers very visible warnings
about it already being installed.
These modules were already manually stripped out from the install,
but we can also skip building them entirely - this gets rid of
30% of the number of lines of log output when building python
(reducing the number of lines from 21539 to 14653 lines, for the
whole of building python for both native and a cross target).
This avoids bloating the wrapper executables, when built for
msvcrt (where the default is to enable __USE_MINGW_ANSI_STDIO
when targeting C99 or newer).
This can happen if the input command line is barely under the limit,
but ends up exceeding it due to the extra arguments that the wrapper
adds.
One could hope that _tspawnvp would set errno to a helpful error code,
to identify the issue when printing the error with _tperror(), but in
practice, it doesn't.
This avoids inflating the total size of the command line too much.
If the input command line is near the max size of a command line
(32767 characters), it may grow past that limit when adding the
arguments injected by the wrapper. If we excessively quote all
arguments that don't need to be quoted, we can more easily run
into this situation.
Thus, by avoiding excessive quoting, we reduce the risk for this
issue to happen.
This avoids the issue reported at
https://github.com/mstorsjo/llvm-mingw/issues/296.
This version fixes some cases of duplicate time.h related symbols,
in some build configurations (an issue only present in the
previous snapshot). This version also uses the right format attributes
for printf/scanf functions for Clang, enabling format string warnings
when using e.g. the mingw ansi stdio routines.
When setting up wrappers for Windows, rename clang-scan-deps.exe to
clang-scan-deps-real.exe, make clang-scan-deps.exe a wrapper, and
configure the wrapper to target executing clang-scan-deps-real.exe.
This makes sure that we always pass in crucial options like
-stdlib=libc++.
By default, our Clang executables are built with that option
hardcoded, configured with CLANG_DEFAULT_CXX_STDLIB=libc++
when built for Windows. However, we generally don't rely on this;
we assume the tools could be plain default executables, so we
try to provide wrappers on all common access paths.
This picks the architecture by looking for a triple prefix in the
nested command, and passes it as an explicit flag, to let
clang-scan-deps find it.
We also pass -stdlib=libc++, to let it find the libc++ headers
as expected.
By default these files would be installed into
${CMAKE_INSTALL_PREFIX}/share/libc++/v1, where
${CMAKE_INSTALL_PREFIX} is equal to ${PREFIX}/${arch}-w64-mingw32.
However, to avoid duplicating these files for each architecture,
install them into ${PREFIX}/share/libc++/v1 instead.
While the files aren't very large (currently weighing in at around
612 KB), they're architecture independent files (and they're
more than a few; they're currently 135 files), so we should
share them if possible.
Currently, the "macos-latest" runners aren't really the latest
version - on the contrary, they're running the oldest HW/OS.
Currently, there are macos-12, macos-13 and macos-14, and macos-latest
are the macos-12 ones.
The macos-14 ones run on Apple Silicon.
Previously, the macos-12 runners have usually managed to run the build
job in less than 3 hours. However, lately, the jobs often end up
taking much longer, over 5 hours, and have ended up exceeding the
6 hour timeout occasionally, even if they still also some times run
in the expected time of less than 3 hours.
Switch to the faster macos-14 runners (which can complete the build
job in around 1 h 40 min), to avoid these timeouts.
This sets the variable CLEAN=1 after building the tools, which makes
all the builds of the runtime libraries remove old build dirs
before building.
This is similar to, but has a slight different purpose than
the existing --wipe-runtimes, which removes the installed runtime
files. Both are useful when testing various build configurations
and investigating issues, for different testing scenarios.
Martin Storsjö