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

[Alp Toker]

On 15/05/2014 01:38, Reid Kleckner wrote:
> On Wed, May 14, 2014 at 3:14 PM, Alp Toker <alp at nuanti.com 
> <mailto: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.

Fascinating :-)

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

I see where you're coming from.

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

Reid, do you think we'll be OK if we can instead find a configure switch 
that forces CMake to believe that we're MSVC for the time being? 
Meanwhile we can work with CMake upstream to resolve detection.

I worry that external tools and projects will start depending on hybrid 
clang-cl.exe options and we'll be stuck with this quirky in-between mode.

We're so close to having clang-cl.exe work as a 100% drop-in cl.exe 
replacement that adding -o in the endgame now seems a shame.

Alp.

-- 
http://www.nuanti.com
the browser experts