This happens in an environment where MSVC was set up first (so env
var VSINSTALLDIR defined), and later prepending a dir such as
`C:\Program Files\Git\usr\bin` to PATH, so that the first link.exe
on PATH isn't the Microsoft one.
In case CC is set try to split it by spaces into a command and
arguments. This is the same behaviour as in dmd.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
Fixes#3535 and an issue for ldmd2 wrt. unquoted args containing spaces
in response files for ldc2 (uncovered during manual tests). Also create
the temporary response files in the temp directory, not in the current
working dir.
This doesn't work for VS 2015, but 2017 and 2019. For VS 2015, I haven't
found a suitable env var, and I don't want to parse LIB and/or PATH to
guess the target architecture (LDC_VSDIR_FORCE can still be used).
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like #3402.
The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
As alternative to clearing VSINSTALLDIR if run in a pre-set environment,
or as alternative to setting LDC_VSDIR to some non-existing dummy dir to
prefer auto-detection and setup of the MSVC toolchain over using the
internal toolchain.
As it's an important option for cross-linking to Posix. It doesn't just
affect linking, but external assembling is probably very exotic
(-no-integrated-as).
And use the wide API for pure is-env-variable-set checks too, as the
first call to a narrow env API function would lead to the C runtime
preparing and maintaining both narrow and wide environments.
Some LLVM libs were missing from the linker flags for current LLVM 5.0.
It was only during troubleshooting that I noticed the MSVC special case in
FindLLVM.cmake. Getting rid of it entirely made the issues disappear. I
checked llvm-config.exe, and it's returning appropriate switches for the
MS toolchain, no need for special processing.
This apparently also leads to LLVM_CXXFLAGS being used for the first time
when building with MSVC. These include /W4, a level further up from
CMake's default /W3, so I disabled a few more frequent warnings.
I also had to link in a lib from Microsoft's Debug Info Access SDK
manually. As the VS command prompt unfortunately doesn't even include the
DIA SDK dir in the LIBPATH environment variable, I even had to specify a
full path, relying on the `VSINSTALLDIR` environment variable.
And merge the two out-of-sync copies for adding gcc target flags. The flag
was omitted for gcc as linker already, but not for gcc as external assembler.
Results in a 7.5% bigger RelWithDebInfo ldc2.exe on Win64 with LLVM 3.9.1.
LLD is currently enforced when building with LDC_WITH_LLD=ON. And LLD
still doesn't support debuginfo (.pdb) generation for MSVC targets.
