win: Add support for VS2015

win: Add support for VS2015

R=sbaig1@bloomberg.net
BUG=chromium:440500
Committed: https://code.google.com/p/gyp/source/detail?r=2013

[Shezan Baig (Bloomberg), 2014-12-09 20:30:00]

LGTM

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

https://codereview.chromium.org/784363003/diff/1/pylib/gyp/msvs_emulation.py#...
pylib/gyp/msvs_emulation.py:464: cflags.append('/FS')
I wonder if we should change the pdb path we pass to cl.exe to be unique for
each source file, that way we don't need to synchronize writing to it.  Just
wondering if you have experimented with that?

[scottmg, 2014-12-09 20:40:23]

On 2014/12/09 20:30:00, Shezan Baig (Bloomberg) wrote:
> LGTM
> 
> https://codereview.chromium.org/784363003/diff/1/pylib/gyp/msvs_emulation.py
> File pylib/gyp/msvs_emulation.py (right):
> 
>
https://codereview.chromium.org/784363003/diff/1/pylib/gyp/msvs_emulation.py#...
> pylib/gyp/msvs_emulation.py:464: cflags.append('/FS')
> I wonder if we should change the pdb path we pass to cl.exe to be unique for
> each source file, that way we don't need to synchronize writing to it.  Just
> wondering if you have experimented with that?

I tried one pdb per source file long ago, but everything falls apart (links took
hours, and many failed with overflow-type errors). But one huge pdb also falls
over. It has to be clumped into "medium sized chunks" as the primary benefit of
the pdb is to de-duplicate type information at compile time, rather than having
the linker do all the work.

I think what we could do is make a ninja pool for each pdb, and set a pool depth
of 1 to have ninja serialize access to the pdb, and then remove /FS. It'd then
be a matter of coming up with a good way to make the assignment of cc to pdb.
Maybe the current assignment by target is enough to start with.

The drawback is that it's statically assigned at gyp time, so that in the worst
case, if you changed something that caused all the cc's that were assigned to
one pdb to rebuild, but no other .ccs, it'd be effectively like ninja -j1.
Without trying it, I don't have a guess as to whether not using /FS would make
up for occasional serialization of compile steps though. It would be interesting
to find out though, perhaps it makes compile a lot faster.

[scottmg, 2014-12-09 20:49:55]

Committed patchset #1 (id:1) manually as 2013.

[Shezan Baig (Bloomberg), 2014-12-09 20:57:31]

On 2014/12/09 20:40:23, scottmg wrote:
> I tried one pdb per source file long ago, but everything falls apart (links
took
> hours, and many failed with overflow-type errors). But one huge pdb also falls
> over. It has to be clumped into "medium sized chunks" as the primary benefit
of
> the pdb is to de-duplicate type information at compile time, rather than
having
> the linker do all the work.
> 
> I think what we could do is make a ninja pool for each pdb, and set a pool
depth
> of 1 to have ninja serialize access to the pdb, and then remove /FS. It'd then
> be a matter of coming up with a good way to make the assignment of cc to pdb.
> Maybe the current assignment by target is enough to start with.
> 
> The drawback is that it's statically assigned at gyp time, so that in the
worst
> case, if you changed something that caused all the cc's that were assigned to
> one pdb to rebuild, but no other .ccs, it'd be effectively like ninja -j1.
> Without trying it, I don't have a guess as to whether not using /FS would make
> up for occasional serialization of compile steps though. It would be
interesting
> to find out though, perhaps it makes compile a lot faster.


Thanks for the explanation!  :)

Hmm, I suppose it's better to just let the compiler do that serialization
internally rather than trying to serialize from outside.  In any case, it
wouldn't be faster than what you would get with 'fastbuild=1' or something
similar.