Get ninja working for nacl.

Get ninja working for nacl.

- Add support for .asm files for win32
- Add support for msvs_target_platform
- Update x64 test to actually do something meaningful relative to how we
  use configurations.

BUG=None
TEST=None
R=scottmg@chromium.org
Committed: https://code.google.com/p/gyp/source/detail?r=1422

[bradn, 2012-06-27 22:44:36]

There's one issue with this (thing marked BOGUS).
I'll come chat in person.

[scottmg, 2012-06-27 23:08:11]

cool, looks good with fix for BOGUS

http://codereview.chromium.org/10698023/diff/1/pylib/gyp/generator/ninja.py
File pylib/gyp/generator/ninja.py (right):

http://codereview.chromium.org/10698023/diff/1/pylib/gyp/generator/ninja.py#n...
pylib/gyp/generator/ninja.py:756: # Asm files only get auto assembled for x86
(not x64).
Is that a TODO? Or does VS actually not run ml64 automatically for .asm in x64
projects?

http://codereview.chromium.org/10698023/diff/1/pylib/gyp/generator/ninja.py#n...
pylib/gyp/generator/ninja.py:758: obj_ext = '_asm.obj'
is there a reason to add _asm to the name?

http://codereview.chromium.org/10698023/diff/1/test/configurations/x64/gyptes...
File test/configurations/x64/gyptest-x86.py (right):

http://codereview.chromium.org/10698023/diff/1/test/configurations/x64/gyptes...
test/configurations/x64/gyptest-x86.py:26:
test.run_built_executable('configurations' + suffix,
This doesn't seem to test too much, since most machines will be x64 now, and
both 32/64 will run fine natively or on wow64.

Maybe instead test.run_dumpbin('/headers', path_to_binary)
and check for containing "14C machine (x86)" for x86
or "8664 machine (x64)" for x64

(test/win/gyptest-link*.py does similar for reference)

[bradn, 2012-06-28 01:37:51]

PTAL,
got the PlatformName working

http://codereview.chromium.org/10698023/diff/1/pylib/gyp/generator/ninja.py
File pylib/gyp/generator/ninja.py (right):

http://codereview.chromium.org/10698023/diff/1/pylib/gyp/generator/ninja.py#n...
pylib/gyp/generator/ninja.py:756: # Asm files only get auto assembled for x86
(not x64).
On 2012/06/27 23:08:11, scottmg wrote:
> Is that a TODO? Or does VS actually not run ml64 automatically for .asm in x64
> projects?

Frighteningly it doesn't run it.

http://codereview.chromium.org/10698023/diff/1/pylib/gyp/generator/ninja.py#n...
pylib/gyp/generator/ninja.py:758: obj_ext = '_asm.obj'
On 2012/06/27 23:08:11, scottmg wrote:
> is there a reason to add _asm to the name?
There's one instance in the code base in which there's actually a .cc and a .asm
with the same name. Apparently whatever msvs is doing to build it allows both to
end up being compiled and linked, so I've added a suffix to avoid collisions.
(Unless they name it _asm).
Adding a comment.

http://codereview.chromium.org/10698023/diff/1/test/configurations/x64/gyptes...
File test/configurations/x64/gyptest-x86.py (right):

http://codereview.chromium.org/10698023/diff/1/test/configurations/x64/gyptes...
test/configurations/x64/gyptest-x86.py:26:
test.run_built_executable('configurations' + suffix,
On 2012/06/27 23:08:11, scottmg wrote:
> This doesn't seem to test too much, since most machines will be x64 now, and
> both 32/64 will run fine natively or on wow64.
> 
> Maybe instead test.run_dumpbin('/headers', path_to_binary)
> and check for containing "14C machine (x86)" for x86
> or "8664 machine (x64)" for x64
> 
> (test/win/gyptest-link*.py does similar for reference)

Done.

[scottmg, 2012-06-28 17:14:32]

lgtm