Not sure who knows MSBuild, so I'm adding several random people in hopes that someone can review this.
I expect this to need to go through a couple of iterations, but this represents a complete re-write of the Clang Visual Studio Integration. I'll try to summarize the high level differences between how this works now and how it used to work, as well as mention some future work I think we should do:
- Previously we would install into %ProgramFiles%\MSBuild. At least with 2017, this no longer appears to be what you do. You now have to install to the VS instance. Rather than try to detect Installed VS Instances from a batch file, for now I just hardcode the path to the default installation path, and in follow-up patches we can port this to using a VSIX installer, which should handle all of this for us.
- Previously we had separate .props and .targets files for every version of VS. This turns out to be unnecessary, so all of those have been removed and now there is just 1. The good news is that this means we should continue to work in subsequent versions of VS without any additional maintenance.
- Previously would do a configure-style modification of the props and targets file to fill in with compile time values. The only one of these that's tricky is the LLVM Version number, the rest are already available via existing MSBuild substitutions. So all of those are fixed, and to handle the version number the installer is updated to write an additional value to the registry, which the MSBuild files pull. Decoupling these values from the particular build of LLVM opens the door for us to be able to package this in a VSIX and distribute it on the marketplace and update it independently of the actual toolchain.
- An xml file is provided to present a custom view of compiler options (e.g. Project > Properties > C/C++). Options we don't support or ignore are grouped together under special tabs in the UI, while the settings we do support are in the original locations. This is done because we additionally will now warn (or error) on certain options which could have been enabled in a project prior to changing the toolset, and we like to be able to point the user exactly to which setting to change to silence the warning / error.
- Previously we would copy clang-cl.exe to $(InstallDir)\bin\cl.exe because this is how MSBuild would find the compiler. This is now fixed so that it locates clang-cl.exe directly.
- Options that we ignore are now not even passed to clang-cl. This might seem unimportant because if we ignore the option, there's no harm in passing it in. But some of these options trigger additional MSBuild logic that happens before the compiler even has a chance to run. For example, in llvm.org/pr36140, a user noted that using /Zi triggered a full rebuild every time, even if nothing changed. In any case, having smaller command lines makes for easier diagnostics. An additional side benefit of this is that whereas before you would get lots of -Wunused-command-line-argument warnings, now there will be no such warnings.
Future Work (in rough order of priority):
- Wrap this all in a VSIX so that it can be properly installed, instead of relying on batch file hackery.
- Expose all of clang warnings through a custom UI page.
- Expose all of clang optimizations through a custom UI page.
- Replace link.exe with lld-link.exe similar to how we currently replace cl.exe with clang-cl.exe
- Install a clang platform (in additional to a platform toolset), so that we have Clang (x86) and Clang (x64) platforms for people to enable building side-by-side configurations.
- Add a Clang (Cross-Platform) platform that exposes the clang++ driver in all of its glory and allows the user to set the target triple.