[PATCH] clang-cl: Add support for -o

[Reid Kleckner]

On Wed, May 14, 2014 at 3:14 PM, Alp Toker <alp at nuanti.com> wrote:

>
> On 15/05/2014 00:08, Reid Kleckner wrote:
>
>> Hi hans,
>>
>> MSVC silently ignores it rather than warning on it, so they have some
>> support for it.
>>
>
> Just to clarify, does MSVC handle -o differently to flags that definitely
> don't exist?


It handles it slightly differently:
$ cl -c t.cpp -ofoo.obj -asdf -nologo
cl : Command line warning D9035 : option 'o' has been deprecated and will
be removed in a future release
cl : Command line warning D9002 : ignoring unknown option '-asdf'

So, it used to know about it, but either way it ignores it.  I doubt they
will add it back with a new meaning in a future release.

    This greatly simplifies wiring clang-cl through CMake
>> and other build systems that use traditional -o compiler flag.
>>
>
> CMake and other build systems already have measures in place to support
> MSVC's cl.exe -- wouldn't that existing support already work satisfactorily
> if you drop clang-cl.exe in its place?
>

I wish I could drop clang-cl into the CMake build.  CMake actually starts
off by doing something like:
${CMAKE_C_COMPILER} -c check_compiler_id.c -ocheck_compiler_id.o

Our handling of -o isn't the real problem, though, because we currently
ignore it just like MSVC does:
$ clang-cl -c t.cpp -ot.obj
clang-cl.exe: warning: argument unused during compilation: '-o t.obj'

So the summary isn't really accurate, this change doesn't improve the
situation with CMake.

---

What actually happens is that CMake sees that __clang__ is defined, and
proceeds to use gcc-style arguments to invoke the compiler.  It also sends
us down the wrong codepaths in CMakeLists.txt where we check for if (MSVC)
when we really mean "are we using MSVCRT".  I haven't had the time to sort
it out.

To self-host, I currently generate a build.ninja file with CMake and
replace the path to cl.exe with a script.  =(  I've been holding off on
documenting self-hosting with clang-cl until that gets fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140514/1b9bdeac/attachment.html>