ninja windows: Support x64 configuration platform

ninja windows: Support x64 configuration platform

This supports top-level x64 configuration so the entire
project can be built as 64 bit. Previously, we only supported
a 64 bit override for individual targets (via msvs_target_platform).

'asm' files were a bit confused before; the intention was that all .asm
be built on Win32, but they were only being built if the msvs_target_platform
was explicitly set which was very confusing. So, support .asm still, but if
the target overrides asm with a rule, then use that one instead, similar to
.idl files. 

BUG=chromium:8606
Committed: https://code.google.com/p/gyp/source/detail?r=1534

[scottmg, 2012-11-08 19:27:44]

Refactor a bit to support building x64 at top-level too.

[Sam Clegg, 2012-11-08 20:14:57]

https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.py
File pylib/gyp/msvs_emulation.py (right):

https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.p...
pylib/gyp/msvs_emulation.py:226: return 'x64' if platform.endswith('x64') else
'x86'
Doesn't this break the case where platform is something
other than "win32" or "x64"?  I am currently using the
msvs_target_platform for other platforms such as NaCl64
and PPAPI.

IIUC Platform != Architecture in MSVS.  There could be many
platforms configured in VS that all run on x86 for example.
win32 is just one of them.

[scottmg, 2012-11-08 21:22:51]

On 2012/11/08 20:14:57, Sam Clegg wrote:
> https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.py
> File pylib/gyp/msvs_emulation.py (right):
> 
>
https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.p...
> pylib/gyp/msvs_emulation.py:226: return 'x64' if platform.endswith('x64') else
> 'x86'
> Doesn't this break the case where platform is something
> other than "win32" or "x64"?  I am currently using the
> msvs_target_platform for other platforms such as NaCl64
> and PPAPI.

Yup, probably! Are those complete toolchains? Or do they assume that cl/link/etc
are available and are the x86-host-x86-target-win32 version?

The main thing the generator needs to know is what PATH/LIB/INCLUDE to set up so
that it ends up with the x86 or x64 (or arm or whatever) toolchains. I'm not
quite clear on how that mapping to compilers happens in VS, other than "Win32"
goes to x86 and "x64" goes to the amd64 compiler.


> 
> IIUC Platform != Architecture in MSVS.  There could be many
> platforms configured in VS that all run on x86 for example.
> win32 is just one of them.

[scottmg, 2012-11-08 21:47:00]

On 2012/11/08 20:14:57, Sam Clegg wrote:
> https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.py
> File pylib/gyp/msvs_emulation.py (right):
> 
>
https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.p...
> pylib/gyp/msvs_emulation.py:226: return 'x64' if platform.endswith('x64') else
> 'x86'
> Doesn't this break the case where platform is something
> other than "win32" or "x64"?  I am currently using the
> msvs_target_platform for other platforms such as NaCl64
> and PPAPI.

Also, can you point me at where/how you're using this? I only found 'Win32' and
'x64' as settings for both 'msvs_configuration_platform' and
'msvs_target_platform'.

Or maybe I'm just completely misunderstanding what you were saying. :)

> 
> IIUC Platform != Architecture in MSVS.  There could be many
> platforms configured in VS that all run on x86 for example.
> win32 is just one of them.

[Sam Clegg, 2012-11-08 21:54:10]

On 2012/11/08 21:47:00, scottmg wrote:
> On 2012/11/08 20:14:57, Sam Clegg wrote:
> >
https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.py
> > File pylib/gyp/msvs_emulation.py (right):
> > 
> >
>
https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.p...
> > pylib/gyp/msvs_emulation.py:226: return 'x64' if platform.endswith('x64')
else
> > 'x86'
> > Doesn't this break the case where platform is something
> > other than "win32" or "x64"?  I am currently using the
> > msvs_target_platform for other platforms such as NaCl64
> > and PPAPI.
> 
> Also, can you point me at where/how you're using this? I only found 'Win32'
and
> 'x64' as settings for both 'msvs_configuration_platform' and
> 'msvs_target_platform'.
> 
> Or maybe I'm just completely misunderstanding what you were saying. :)

I'm using these settings in automatically generated gyp files for
the NaCl example.

Its a little obscure so I can see how you would have missed it if you
were searching the chrome source code:

src/native_client_sdk/src/build_tools/dsc2gyp.py

This script converts our example description files into
gyp files that can then be used to generate VS projects.
We're not yet using this code in production but we plan
to very soon.

> 
> > 
> > IIUC Platform != Architecture in MSVS.  There could be many
> > platforms configured in VS that all run on x86 for example.
> > win32 is just one of them.

[Sam Clegg, 2012-11-08 22:06:24]

On 2012/11/08 21:54:10, Sam Clegg wrote:
> On 2012/11/08 21:47:00, scottmg wrote:
> > On 2012/11/08 20:14:57, Sam Clegg wrote:
> > >
> https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.py
> > > File pylib/gyp/msvs_emulation.py (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/11363143/diff/2001/pylib/gyp/msvs_emulation.p...
> > > pylib/gyp/msvs_emulation.py:226: return 'x64' if platform.endswith('x64')
> else
> > > 'x86'
> > > Doesn't this break the case where platform is something
> > > other than "win32" or "x64"?  I am currently using the
> > > msvs_target_platform for other platforms such as NaCl64
> > > and PPAPI.
> > 
> > Also, can you point me at where/how you're using this? I only found 'Win32'
> and
> > 'x64' as settings for both 'msvs_configuration_platform' and
> > 'msvs_target_platform'.
> > 
> > Or maybe I'm just completely misunderstanding what you were saying. :)
> 
> I'm using these settings in automatically generated gyp files for
> the NaCl example.
> 
> Its a little obscure so I can see how you would have missed it if you
> were searching the chrome source code:
> 
> src/native_client_sdk/src/build_tools/dsc2gyp.py
> 
> This script converts our example description files into
> gyp files that can then be used to generate VS projects.
> We're not yet using this code in production but we plan
> to very soon.
> 
> > 
> > > 
> > > IIUC Platform != Architecture in MSVS.  There could be many
> > > platforms configured in VS that all run on x86 for example.
> > > win32 is just one of them.

Sorry. I misunderstood this change.  I'm only worked about non-standard platform
names in the MSVS generator itself.  Getting ninja to support non-standard
MSBuild platforms seems like it would be whole lot more work and isn't something
I need to have happen.   So limiting the platforms that ninja supports to only
win32 and x64 seems fine for now.

[scottmg, 2012-11-08 22:29:16]

To recap what Sam and I talked through, ninja effectively understands 'Win32'
and 'x64' as special platforms (similar to how VS2008 worked I think) but
MSBuild (2010+) supports pluggable toolchains.

To emulate MSBuild's support of these toolchains would involve interpreting the
XML in the MSBuild distribution (multiple megabytes of complex script) so isn't
too practical (or interesting :) to pursue.

This sort of makes sense because the windows-specific bits of gyp really map to
the vs2008 DOM (not 2010/msbuild).

The changes in this CL only affect the ninja generator, so don't have any impact
(positive or negative) on the msvs generator.

[scottmg, 2012-11-09 18:04:05]

http://codereview.chromium.org/11363143/diff/7004/test/rules/src/subdir4/buil...
File test/rules/src/subdir4/build-asm.gyp (right):

http://codereview.chromium.org/11363143/diff/7004/test/rules/src/subdir4/buil...
test/rules/src/subdir4/build-asm.gyp:26: 'asm-function.assem',
We _weren't_ running the implicit .asm build rule because there's no
msvs_configuration_platform/msvs_target_platform specified here. Made it .assem
since the test intends it not to run.

[scottmg, 2012-11-12 18:11:55]

ping, brad (or sam if you feel qualified)

[bradn, 2012-11-13 18:19:07]

Much of it seems like good refatoring, but I'm clearly missing what was broken
before (and what actually change is occurring). Swinging by in person.

https://chromiumcodereview.appspot.com/11363143/diff/7004/pylib/gyp/msvs_emul...
File pylib/gyp/msvs_emulation.py (right):

https://chromiumcodereview.appspot.com/11363143/diff/7004/pylib/gyp/msvs_emul...
pylib/gyp/msvs_emulation.py:240: config = config[:-4]
-4 makes me sad, maybe:
config = config.rsplit('_', 1)[0]
or
config = config[:-len('_x64'))

[scottmg, 2012-11-13 18:25:07]

(and added to description)

https://chromiumcodereview.appspot.com/11363143/diff/7004/pylib/gyp/msvs_emul...
File pylib/gyp/msvs_emulation.py (right):

https://chromiumcodereview.appspot.com/11363143/diff/7004/pylib/gyp/msvs_emul...
pylib/gyp/msvs_emulation.py:240: config = config[:-4]
On 2012/11/13 18:19:08, bradn wrote:
> -4 makes me sad, maybe:
> config = config.rsplit('_', 1)[0]
> or
> config = config[:-len('_x64'))

Done.

[bradn, 2012-11-13 18:25:50]

LGTM, with nits.

Could we make the commit message a little more clear?
From our conversation my understanding is that per target target_platform, is
working, but not solution level. So for instance nacl64.exe which is part of the
Win32 solution, builds as x64, works, but building all targets as x64 doesn't.

Also, minor worry. Will this cause ninja to suddenly build everything in the x64
configuration as well as Win32, or will something keep it off initially that I'm
missing?

[scottmg, 2012-11-13 18:31:01]

On 2012/11/13 18:25:50, bradn wrote:
> LGTM, with nits.
> 
> Could we make the commit message a little more clear?

Done.

> From our conversation my understanding is that per target target_platform, is
> working, but not solution level. So for instance nacl64.exe which is part of
the
> Win32 solution, builds as x64, works, but building all targets as x64 doesn't.

That's right.

> Also, minor worry. Will this cause ninja to suddenly build everything in the
x64
> configuration as well as Win32, or will something keep it off initially that
I'm
> missing?

There's separate configs for the different bitsize, i.e. sunrelated out\Debug
and out\Debug_x64 directories. So, nothing unexpected should happen with this
change. I will have to get another gypbot set up to test this variation as well
though.

[bradn, 2012-11-13 20:09:59]

Cool. LGTM