The wrapper script no longer has any purpose on Unix.
Just do a plain symlink to the clang-scan-deps tool.
On Windows, the wrapper executable still is used to inject a
default -target option, if the executable name doesn't contain
a triple.
Clang only picks up config files implicitly using the normalized
triple form, so use file names with "-windows-gnu" instead of
"-mingw32".
In theory, we could also want to pick up the config file implicitly
by having "<triple>-<mode>" be a symlink directly to the clang
executable. That works for regular mingw32 targets, but for the
mingw32uwp target, there's no distinction in the normalized
triple, so both would end up using the same "-windows-gnu" config
files. So as long as we want to support the mingw32uwp prefixed
tools, we need to use a wrapper.
The wrapper script no longer has any purpose on Unix.
Just do a plain symlink to the clang-scan-deps tool.
On Windows, the wrapper executable still is used to inject a
default -target option, if the executable name doesn't contain
a triple.
Clang only picks up config files implicitly using the normalized
triple form, so use file names with "-windows-gnu" instead of
"-mingw32".
In theory, we could also want to pick up the config file implicitly
by having "<triple>-<mode>" be a symlink directly to the clang
executable. That works for regular mingw32 targets, but for the
mingw32uwp target, there's no distinction in the normalized
triple, so both would end up using the same "-windows-gnu" config
files. So as long as we want to support the mingw32uwp prefixed
tools, we need to use a wrapper.
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).
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.
add an option --host-clang which will skip building llvm,
and instead provide symlinks and wrappers for clang and
llvm tools.
Currently the clang version is detected, but it does not
affect the llvm version that will be downloaded and used.
This is necessary for CMake to detect working IPO (LTO); if the
compiler is named <target>-{gcc,clang}, CMake expects to find
matching tools named <target>-llvm-{ar,ranlib} too. (The CMake
module CheckIPOSupported and function check_ipo_supported expects
to have CMAKE_LANG_COMPILER_AR and ..._RANLIB set to working tools;
the Clang-FindBinUtils.cmake module looks for tools named
llvm-ar/llvm-ranlib with the same prefix as the compiler.)
A regular GCC install doesn't provide tools like <triple>-{cc,c99,c11},
so there's probably not much need to include them.
Some distributions of tools may provide tools with the names "cc",
"c99" and "c11" though, as custom frontends or symlinks to the
regular compiler. Therefore, keep the unprefixed tools with these
names.
This includes building universal binaries (for arm64 and x86_64)
and targeting an older minimum deployment target.
(Before 1919720fdd348ca568b235bf3f1357c198eccd15 in llvm-project,
Jan 2022, building lldb's debugserver failed, if building for macOS
for multiple architectures, or for an architecture other than the
current host.)
Since LLVM 13, llvm-dlltool can imply the target architecture from
a triple prefix on the tool name, so there's no more need for a
wrapper.
The *-dlltool tools are now symlinks to the main llvm-dlltool
executable. In the Windows distribution, the *-dlltool.exe used to be
copies of dlltool-wrapper.exe (which is small; 15 KB). Now they
will instead be copies of llvm-dlltool.exe. Luckily, thanks to
building with -DLLVM_LINK_LLVM_DYLIB=ON by default, llvm-dlltool.exe
is only a mere 65 KB, while it used to be much larger, e.g. around
11 MB in older releases.
Printing '<triple>' causes the shell to try to read a file named
triple. One could either quote it, or just remove the angle brackets;
removing the brackets for simplicity.
On windows, we rename clang.exe to clang-$MAJOR.exe, and later
install clang.exe as a wrapper for the default architecture. But
if only building certain architectures, and the host architecture
isn't one of them, we shouldn't install any unprefixed clang.exe at
all.
For build-mingw-w64.sh to succeed when installing to such a path,
the mingw-w64 version has to be updated to the latest git master.
build-mingw-w64-libraries.sh still fails in this case, as libtool
fails to properly quote $LD in a test for whether the linker is GNU ld.
This saves a lot of diskspace, when symlinks are turned into full
copies of the tools on windows, as the symlinks only point to a small
wrapper instead of to the full tool.
Mateusz Mikuła