[cfe-dev] cl.exe (MS Visual Studio) compatible driver.

[Michael Spencer]

I have finally gotten to the point in Windows support where the lack
of a cl.exe (the C/C++ compiler included with Microsoft Visual Studio)
compatible driver for clang is getting in the way.

The main problem currently is external library specification. With
cl.exe, to compile a GUI application, your command line would be:

cl.exe GUIProgram.c User32.lib

Which would output GUIProgram.obj and GUIProgram.exe. Currently I have
to have a separate compile and link stage for this to work:

clang -o GUIProgram.obj GUIProgram.c
link -out:GUIProgram.exe GUIProgram.obj libcmt.lib User32.lib

Not a big deal, but annoying enough for me to get started on this.



We have actually discussed this quite a bit in the past, but have yet
to come to a consensus on exactly how to implement it. I will
summarize the current ideas I know of.

The simplest and lowest impact to the clang codebase solution is a
simple script wrapper around clang. This would take cl.exe style
commands (which can start with either '-' or '/') and covert them to
unix/gcc style. This is simple, but requires adding lots of weird
options to clang that duplicate the cl.exe options in a unix/gcc
style. It would also have to understand the cl.exe and link.exe
library search paths to be able to convert a library (such as
User32.lib) into its absolute path for clang to use.

The second solution, and most supported from people I have talked to,
is to have an actual separate driver called clang-cl (or ms, or w/e
else someone feels like). This doesn't necessarily have to be a
separate binary, and could simply use the same mechanism that is used
to detect clang++. This would emulate the cl.exe driver and call clang
-cc1 on its own. It would use as much existing driver infrastructure
as possible. The issue with this method is mapping custom clang
commands to the cl.exe style interface, as we would need to know which
options should be replaced by cl.exe style, and which shouldn't
(because there are no replacements).

The third option (which apparently only I like :P) is to have a
separate driver similar to the above, but instead of using different
options, it would merge the two. This would allow using all of the
existing clang options in addition to the cl.exe options. In any case
where there is a conflict (which there are very few, due to cl.exe
preferring uppercase and two to three letter options), the cl.exe
style would override. The main problem with this method is dealing
with conflicts. The major one being '/' as an option indicator. This
complicates using absolute paths that begin with /, although this is
rarely used on Windows. They are, however, used in MinGW, but as MinGW
is gcc compatible, I see no reason that clang-cl would ever be used
with MinGW.

This last solution would allow:

clang-cl GUIProgram.c User32.lib /Ox -fcatch-undefined-behavior

This binary will only be present when compiled with MSVC (and clang
built this way once self-hosting works), and thus will not affect any
other platform.

- Michael Spencer