Support overriding path to VS without referring to the registry.

Support overriding path to VS without referring to the registry.

Add GYP_MSVS_OVERRIDE_PATH to point directly to a compiler installation.
Previously, the registry was always used to determine install paths for
compilers, but this allows pointing at a toolchain without requiring
any global state changes.
Committed: https://code.google.com/p/gyp/source/detail?r=1556

[scottmg, 2013-01-02 17:18:49]

Does this seem OK?

(In support of https://codereview.chromium.org/11633012/)

[Nico, 2013-01-02 17:23:26]

lgtm

I assume something will set all these env vars automatically?

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

https://codereview.chromium.org/11637025/diff/2001/pylib/gyp/MSVSVersion.py#n...
pylib/gyp/MSVSVersion.py:363: 'set to an "e" version (e.g. 2010e)')
Might be easier to silently default to 2010e?

[scottmg, 2013-01-02 17:41:24]

On 2013/01/02 17:23:26, Nico wrote:
> lgtm
> 
> I assume something will set all these env vars automatically?

Yes, the toolchain script sets them up.

> 
> https://codereview.chromium.org/11637025/diff/2001/pylib/gyp/MSVSVersion.py
> File pylib/gyp/MSVSVersion.py (right):
> 
>
https://codereview.chromium.org/11637025/diff/2001/pylib/gyp/MSVSVersion.py#n...
> pylib/gyp/MSVSVersion.py:363: 'set to an "e" version (e.g. 2010e)')
> Might be easier to silently default to 2010e?

Hmm, might be. I think I'd rather not since the current 'auto'matic behavior is
2010 (non-e), whereas this would be automatic 2010 with-e. In particular, it
would still need a check for it being set to "2010" (rather than unset) as 2010
(non-e) won't work with the environment setup code.

The script sets both variables anyway, so it shouldn't be an issue in practice
until someone else (non-Chromium) wants to use OVERRIDE_PATH.