ninja win: Don't return unfound VS version, raise instead

Like r1978, but for ninja only.  The msvs generator can use the fallback, but
the ninja generator cannot do anything without knowing the path to the VS
installation.  It is better to fail here, than to fail further along when
trying to run the setup script.

BUG=
R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/708303002

git-svn-id: http://gyp.googlecode.com/svn/trunk@1999 78cadc50-ecff-11dd-a971-7dbc132099af
Fix dependency broken on mac when building FAT binaries.

When trying to build shared_library or loadable_module, build.ninja
has a rule to depend on .dylib.TOC or .so.TOC.  However, WriteLink in
ninja.py forget to create the rule for .TOC for FAT binaries.
As a result, generated build.ninja won't has a rule for .TOC,
which cause build failure.

Note that I only fixed a part of the issue 411, which is needed for my goal.
I or somebody else need more work to make gyp in the issue 411 work
as epxected.

BUG=https://code.google.com/p/gyp/issues/detail?id=411
Review URL: https://codereview.chromium.org/629893002/

Patch from Yoshisato Yanagisawa <yyanagisawa@chromium.org>!


git-svn-id: http://gyp.googlecode.com/svn/trunk@2000 78cadc50-ecff-11dd-a971-7dbc132099af
Revert r1998, it breaks iOS builds

BUG=chromium:432483
TBR=maruel@chromium.org

Review URL: https://codereview.chromium.org/722773002

git-svn-id: http://gyp.googlecode.com/svn/trunk@2001 78cadc50-ecff-11dd-a971-7dbc132099af
win: Use the _winreg module for registry access

This commit changes the Visual Studio installation path detection code to use
_winreg to find the installation path in the registry.  The previous method of
using reg.exe is preserved as a fallback for when '_winreg' cannot be imported
(for example in cygwin).

Also, remove the '_RegistryKeyExists' function since it is not used anywhere.

BUG=
R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/724863002

git-svn-id: http://gyp.googlecode.com/svn/trunk@2002 78cadc50-ecff-11dd-a971-7dbc132099af
ninja win: Add msvs emulation for FloatingPointModel

BUG=
R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/720153005

git-svn-id: http://gyp.googlecode.com/svn/trunk@2003 78cadc50-ecff-11dd-a971-7dbc132099af
Add support for "else if" in gyp conditions

Right now, a gyp condition consists of exactly two or three parts:

  [cond_expr, true_dict]
  [cond_expr, true_dict, false_dict]

This means if we want to have an "else if" condition, it needs to be inside a
nested 'conditions' list inside the false_dict.  This leads to unnecessarily
deep levels of nesting in gyp files.

This commit makes it so that if the 'false_dict' is not a dict, then we will
treat it as another cond_expr.  We keep looping like this until we find a
false_dict, or until we reach the end of the list.

This means we can now have conditions that look like this:

  [cond_expr1, true_dict1, cond_expr2, true_dict2, false_dict]

or:

  [cond_expr1, true_dict1, cond_expr2, true_dict2, cond_expr3, true_dict3]

BUG=
R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/601353002

git-svn-id: http://gyp.googlecode.com/svn/trunk@2004 78cadc50-ecff-11dd-a971-7dbc132099af
Mechanical changes to cleanup pylint presubmit checks

BUG=gyp:469
R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/739303003

git-svn-id: http://gyp.googlecode.com/svn/trunk@2006 78cadc50-ecff-11dd-a971-7dbc132099af
Add back support for /Gv now that gyp-win64 has VS2013

This was removed in the last minute in r1984 because of failures in the
gyp-win64 bot.

BUG=
R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/645223002

git-svn-id: http://gyp.googlecode.com/svn/trunk@2007 78cadc50-ecff-11dd-a971-7dbc132099af
Initialize struct flock for AIX with O_LARGEFILE used by Python.

gyp issue 440

Python on AIX is compiled with LARGEFILE support.  gyp flock_tool must
use the appropriate stucture member definitions to properly initialize
the structure.

BUG=
Review URL: https://codereview.chromium.org/738943004/
Patch from David Edelson <dje.gcc@gmail.com>!


git-svn-id: http://gyp.googlecode.com/svn/trunk@2008 78cadc50-ecff-11dd-a971-7dbc132099af
ninja/win: Let link-wrapper convert /s to \s in the linker command.

ExecLinkWrapper() runs a subprocess with shell=True, so that "link.exe" is
looked up using PATH from the environment loaded from environment.x86 in the
build directory.

shell=True implies that forward slashes in the path to the linker (say, if a
custom linker, such as lld-link.exe is used) don't work. If the linker command
is '..\../lld-link.exe', the command with fail with
"'..\..' is not recognized as an internal or external command".

So manually replace forward slashes with backslashes in the link command before
attempting to run it.

BUG=chromium:436277
Review URL: https://codereview.chromium.org/722073004/



git-svn-id: http://gyp.googlecode.com/svn/trunk@2009 78cadc50-ecff-11dd-a971-7dbc132099af
android: don't try to handle suppress_wildcard.

When deciding whether to include a target in the generated makefiles or
not, don't consider the suppress_wildcard flag as this just means that
any target which depends directly on the target in question will crash
gyp. The exact contents of the "all" target on the android backend are
not really relevant, so this is the simplest fix.

BUG=chromium:435772
R=thakis@chromium.org

Review URL: https://codereview.chromium.org/758943002

git-svn-id: http://gyp.googlecode.com/svn/trunk@2010 78cadc50-ecff-11dd-a971-7dbc132099af
Fixed Gyp Xcode generator for libraries with identical names.

The Xcode generator produces the same hash for library target products that have
identical names and are defined in .gyp files with identical names that have
different source tree roots. The fix consists of setting the (already defined)
'projectRoot' property on the PBXProject object and adding it to the hashables
of this class.

Patch by Johannes Sartisohn <jsartisohn@google.com>

R=mark@chromium.org

Review URL: https://codereview.chromium.org/748793002

git-svn-id: http://gyp.googlecode.com/svn/trunk@2011 78cadc50-ecff-11dd-a971-7dbc132099af
Cache data for included files in the multiprocess load codepath

When running gyp with --no-parallel, the build file data for included gypi
files is cached in the 'data' dict, so we never load gypi files more than once.

However, when running in parallel mode, the |data| and |aux_data| parameters
passed to CallLoadTargetBuildFile are always empty.  That means gypi files are
reloaded for every single gyp file.

This commit changes CallLoadTargetBuildFile to use a global |per_process_data|
and |per_process_aux_data|, instead of accepting them as parameters.  This
allows each subprocess to get gypi file data from this per-process cache if it
has already encountered the gypi file when loading a previous target build
file.

Another minor change in this commit is to remove aux_data from ParallelState.
The aux_data is only ever used within the scope of LoadTargetBuildFile, so we
don't need to communicate it back to the main process.

BUG=
R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/773883002

git-svn-id: http://gyp.googlecode.com/svn/trunk@2012 78cadc50-ecff-11dd-a971-7dbc132099af
Merge pull request #1 from svn2github/master

merge from the major github repository