Make backends robust to rules and actions containing slashes 

TEST=test/sanitize-rule-names/

Review URL: http://codereview.chromium.org/10535052/
Patch from Steve Block <steveblock@chromium.org>

git-svn-id: http://gyp.googlecode.com/svn/trunk@1411 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: support alternative entrypoints.

'EntryPointSymbol' translates to /ENTRY: in linker flags.  This is needed by Chrome's mini_installer target.

BUG=none
TEST=python gyptest.py -f msvs,ninja test/win/gyptest-link-entrypointsymbol.py
Review URL: https://chromiumcodereview.appspot.com/10544049

git-svn-id: http://gyp.googlecode.com/svn/trunk@1412 78cadc50-ecff-11dd-a971-7dbc132099af
Fix make backend to correctly handle rules with output files of the same name

TEST=test/same-rule-output-file-name
Review URL: http://codereview.chromium.org/10538055/
Patch from Steve Block <steveblock@chromium.org>!

git-svn-id: http://gyp.googlecode.com/svn/trunk@1413 78cadc50-ecff-11dd-a971-7dbc132099af
Rename test/same-name to test/same-source-file-name

TEST=test/same-source-file-name


git-svn-id: http://gyp.googlecode.com/svn/trunk@1414 78cadc50-ecff-11dd-a971-7dbc132099af
Fix make and ninja backends to sensibly handle duplicate target names in different directories 

Currently, if two multiple targets in different directories use the same name, 
gyp's behaviour depends on the particular backend and is confusing at best. See 
bug for details. 

This change fixes the make and ninja backends to ... 
- always build all targets when duplicate targets exist 
- use the correct action/rule/copy when such duplicate targets define 
actions/rules/copies with the same name 

It also adds a test for this. 

BUG=gyp:270
TEST=test/same-target-name-different-directory/ 
Review URL: https://chromiumcodereview.appspot.com/10447063

git-svn-id: http://gyp.googlecode.com/svn/trunk@1415 78cadc50-ecff-11dd-a971-7dbc132099af
Don't make the description for external rules contain the rules' commands.

The description for external rules (where msvs_external_rule != 0) had been set to the full command.  As it happens, MSBuild will generate command shell scripts that echo the description (look, ma, I found a command shell injection vulnerability in MSBuild!).  Let's say you have an external rule that does something like:

  foo && bar && baz && bletch

MSBuild takes that and shoves it into a script file that looks not too unlike:

  echo foo && bar && baz && bletch

  foo && bar && baz && bletch

MSBuild then fires up a cmd.exe at that file.  What's the first line gonna do?  Well, it'll send "foo" to stdout and then run bar && baz && bletch.  Is this harmful?  Well, if "foo" happens to actually be something like "call .....\setup_env.bat", then the env isn't set up.  If you're lucky, bar, baz, and bletch don't happen to be in your path, so you never even know this happened.  If you're unlucky, some subset of them are in your path so you get odd behavior (especially if the ones in your path aren't compatible with the expected ones) like modal error dialogs.  If you're another kind of unlucky, bar, baz, and bletch will succeed (chewing up time, disk, memory, and other things) and then be run a second time.  So now your build succeeds but all external rules take twice as long as they should.  Feh.

Anywhoo, this trivial change makes the description something more neutral which shows up in MSBuild log files as "Running external rules for FOOBAR (TaskId:nnn)".

BUG=none
TEST=python gyptest.py -f msvs test\rules\gyptest-all.py
Review URL: https://chromiumcodereview.appspot.com/10556040

git-svn-id: http://gyp.googlecode.com/svn/trunk@1416 78cadc50-ecff-11dd-a971-7dbc132099af
Print full path in diagnostic messages building with ninja on windows.

This allows to click on messages in visual studio to open file with error or warning.
By default all path is relative to src/out/Debug but visual studio search file relative to location project.

Putting project into deeper directory to match default relative path is an option, but in this case you can't use 'Show All Files' in solution explorer to browse source tree.

BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/10537170

git-svn-id: http://gyp.googlecode.com/svn/trunk@1417 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: Use $in_newline instead of $in in response files

Previously, local version of ninja had modified $in to be \n separated when in response files. Upstream ninja now has $in_newline instead so use that where necessary.

R=thakis@chromium.org

Review URL: https://chromiumcodereview.appspot.com/10614004

git-svn-id: http://gyp.googlecode.com/svn/trunk@1418 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: extract environment during generation and set it per subprocess

Instead of having one wrapper that happens pre-ninja to set up the compiler
environment, extract the required environment at generation time and save it
to a file in the build dir. Then, wrap toolchain invocations to use the saved
environment rather than the parent environment. This has two benefits: 1)
isolation from the parent environment which may not be correctly set up, or
required complicated futzing in wrapper scripts to get set up; 2) gets closer
to allowing support of msvs_target_platform which has a sub-x64 build even
when doing an x86 build (that isn't done here though).

Note: This needs to be rolled at the same time as https://chromiumcodereview.appspot.com/10399040
(as set_environment.bat that ninja.bat looks for is no longer generated).

R=thakis@chromium.org
BUG=127459

Review URL: https://chromiumcodereview.appspot.com/10382158

git-svn-id: http://gyp.googlecode.com/svn/trunk@1419 78cadc50-ecff-11dd-a971-7dbc132099af