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.
For invoking MS tools such as link.exe and lib.exe, which require
compatible PATH, LIB, LIBPATH etc.
We previously wrapped the invokation of the tool with a batch file taking
care of setting up the environment and then calling the actual tool.
I changed this to first invoke another batch file setting up its
environment and then dumping all environment variables to a file. LDC then
parses this file and updates its own environment variables. Later spawned
child processes then inherit the updated environment, and the tools will
be located by LLVM in updated PATH.
This allows LDC to keep track of the used Visual C++ installation (and
could so set up additional runtime libs required since VS 2015, something
we would have needed some time back when we still supported VS 2013). It's
also required as a prerequisite for integrating LLD as in-process linker
on Windows.
I quickly looked into the option of setting up the environment manually,
but the MS batch files are full of quirks, mixtures of registry and
file-system lookups, checking for existence of misc. headers to filter out
bogus installations etc. With VS 2017, there's nothing in the registry at
all anymore (at least for the Build Tools); MS expose a COM interface for
querying the VS installer... But at least they still provide the batch
files.
