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

[Douglas Gregor]

On Apr 12, 2011, at 2:38 AM, Konstantin Tokarev wrote:

> 
> 
> 12.04.2011, 04:30, "Douglas Gregor" <dgregor at apple.com>:
>> 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.
> 
> Maybe it should be called "cl.exe" to be able to replace original cl.exe inside Visual Studio?


Please don't. If Clang actually becomes a suitable replacement compiler for Visual Studio, we can then discuss how best to integrate Clang. The answer is almost certainly not going to just be "call it cl.exe".

	- Doug