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

[Konstantin Tokarev]

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?

-- 
Regards,
Konstantin