<div dir="ltr"><div>I'd like there to be a cl.exe compatible clang driver.  I think the best way for this to work is to have the existing clang driver detect when it's being invoked as cl.exe, similar to how clang++ vs. clang works today.  For testing, there should be a -ccc-msvc option which turns on the same behavior.</div>
<div><br>Some relevant past discussion on this topic:</div><div><a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014402.html</a><br></div><div>
<br></div><div>The priorities for the driver should be, in order:</div><div><br></div><div>1. Drop in compatibility with MSVC</div><div>2. Compatibility with the existing clang driver</div><div>3. Don't change the meaning of existing gcc-style driver command lines (an argument with a / prefix is an input path, not an option)</div>
<div>4. Avoid -cc1 option explosion by aliasing MSVC options to gcc options as much as possible</div><div><br></div><div>I think #2 is important so that cross-platform projects (like LLVM) won't have to spell clang options like -fcolor-diagnostics or -Wc++11-extensions twice.</div>
<div><br></div><div>It's important to know that there are a few conflicts with MSVC like -MD, -MT, and things like -Zi where clang accepts -Z as a joined option, so there needs to be a good solution for disambiguating them.</div>
<div><br></div><div>Previously people have discussed using the slash prefix to disambiguate between the MSVC and clang meanings, but since cl.exe accepts both - and / prefixes for all of its options, I don't like this approach.  There are probably many Unix expats out there on Windows consistently using dash-style option prefixes everywhere, like me.</div>
<div><br></div><div>I think clang should give a higher precedence to all MSVC options before falling back to gcc style options.  To resolve conflicts, there will have to be an escape flag.  I propose -Xclang-driver, which is similar to -Xclang, except that it gets interpreted by the driver.  Hopefully Microsoft never adds an -Xclang-driver flag.  :)</div>
<div><br></div><div>Going forwards, Microsoft will probably add more flags to cl.exe.  If they do and they conflict, we should value drop in compatibility above backwards compatibility and interpret the option as MSVC does, requiring users to use the escape if they need the conflicting option.</div>
<div><br></div><div>I've attached patches for LLVM and clang to start implementing this.  They're pretty rough, but I really want to get something committed and iterate on it, even if I back up and completely rewrite with a separate OptTable.  I've been testing the driver by renaming clang.exe to cl.exe and putting it in the cwd before running MSBuild.  It currently fails due to UTF-16 response files and -Fo takes an output directory which needs -cc1 logic.</div>
<div><br></div><div>Thoughts?</div><div><br></div></div>