Ninja generator: support using clang-cl for Windows

Ninja generator: support using clang-cl for Windows

If CC is set to 'clang-cl' in make_global_settings, use that
as the compiler instead of cl.exe from the environment.

BUG=82385
1846

[hans, 2014-01-28 17:42:37]

Here's a stab at using clang-cl in the windows build. The idea is that the gyp
files expose this option via make_global_settings.

[Nico, 2014-01-28 17:48:19]

+Scott, in case he has an opinion on how this should be exposed.

https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
File pylib/gyp/generator/ninja.py (right):

https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
pylib/gyp/generator/ninja.py:1721: path = clang_cl
Can't you use one of the existing keys (CC or CXX, and maybe warn if both are
set to different values) instead?

[scottmg, 2014-01-28 17:59:02]

https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
File pylib/gyp/generator/ninja.py (right):

https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
pylib/gyp/generator/ninja.py:1721: path = clang_cl
On 2014/01/28 17:48:20, Nico wrote:
> Can't you use one of the existing keys (CC or CXX, and maybe warn if both are
> set to different values) instead?

That sounds better to me.

https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
pylib/gyp/generator/ninja.py:1726: command += (' -m32' if arch == 'x86' else '
-m64')
Slightly concerned about this as it's expecting a binary for CreateProcess, but
I think it'll work ok because of the ninja -t wrapper. Is there somewhere to get
it into cflags instead?

(It'll be nice to get rid of the ridiculous path manipulation we have to do for
cl, some day.)

[hans, 2014-01-28 17:59:09]

On 2014/01/28 17:48:19, Nico wrote:
> +Scott, in case he has an opinion on how this should be exposed.
> 
>
https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
> File pylib/gyp/generator/ninja.py (right):
> 
>
https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
> pylib/gyp/generator/ninja.py:1721: path = clang_cl
> Can't you use one of the existing keys (CC or CXX, and maybe warn if both are
> set to different values) instead?

I'm confused by the role if CC and CXX in the Windows build. From what I
understand, it's only cl_x86 and cl_x64 that are actually used for building
(this is what gyp.msvs_emulation.GenerateEnvironmentFiles returns), and
according to the comment at ninja.py:1667, c99conv.py "needs something valid
here".

I could hook it up so that "if CC/CXX are clang-cl, then stick that in
cl_x86/cl_x64", but I'm not sure if that's any less confusing :)

[scottmg, 2014-01-28 18:07:47]

On 2014/01/28 17:59:09, hans wrote:
> On 2014/01/28 17:48:19, Nico wrote:
> > +Scott, in case he has an opinion on how this should be exposed.
> > 
> >
>
https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
> > File pylib/gyp/generator/ninja.py (right):
> > 
> >
>
https://codereview.chromium.org/136113016/diff/20001/pylib/gyp/generator/ninj...
> > pylib/gyp/generator/ninja.py:1721: path = clang_cl
> > Can't you use one of the existing keys (CC or CXX, and maybe warn if both
are
> > set to different values) instead?
> 
> I'm confused by the role if CC and CXX in the Windows build. From what I
> understand, it's only cl_x86 and cl_x64 that are actually used for building
> (this is what gyp.msvs_emulation.GenerateEnvironmentFiles returns), and
> according to the comment at ninja.py:1667, c99conv.py "needs something valid
> here".

Yeah, it sucks. cl_x86/cl_x64 were the first step in trying to get rid of the
"ninja -t msvc -e $arch --" wrapper around all cl calls. Because all cls
(natives, crosses) are all called "cl.exe" and their support DLLs are in a mix
of locations the environment has to be manipulated for each child process.
That's (currently) all the ninja -t msvc accomplishes. Ideally, ninja would
accept an environment block for the child baked in the rule/build, but I never
finished adding that.

> 
> I could hook it up so that "if CC/CXX are clang-cl, then stick that in
> cl_x86/cl_x64", but I'm not sure if that's any less confusing :)

I think that'd be slightly better, if only because from the outside it's what
people would expect to set. (I agree it's not great though.)

[hans, 2014-01-28 19:32:02]

On 2014/01/28 18:07:47, scottmg wrote:
> > I could hook it up so that "if CC/CXX are clang-cl, then stick that in
> > cl_x86/cl_x64", but I'm not sure if that's any less confusing :)
> 
> I think that'd be slightly better, if only because from the outside it's what
> people would expect to set. (I agree it's not great though.)

OK, I've uploaded a new patch.

[scottmg, 2014-01-28 19:36:09]

lgtm

[Nico, 2014-01-28 21:45:35]

r1846