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

[Douglas Gregor]

On Apr 3, 2011, at 7:21 PM, Michael Spencer wrote:

> 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).

I, personally, like this option the best. It would also allow, e.g., libclang to have a nice entrypoint for creating a translation unit after parsing the cl.exe-style options.

	- Doug