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

[Alp Toker]

On 15/05/2014 02:05, Alp Toker wrote:
>
> 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.

One tidy way to deal with the problem described is to move the __clang__ 
define here..

   if (!LangOpts.MSVCCompat) {
     // Currently claim to be compatible with GCC 4.2.1-5621, but only 
if we're
     // not compiling for MSVC compatibility
     ...
     Builder.defineMacro("__GNUC__", "4");
     ...
}

This seems relatively harmless and clang's compiler feature check macros 
will still work fine.

If/when the CMake detection problem gets resolved we can re-evaluate 
defining __clang__ in the drop-in MSVC compatibility mode.

This feels more progressive to me than making clang-cl.exe look like 
clang.exe with a -o option. What do you think?

Alp.



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