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 <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
