ninja windows: support .def files for exports (also exe for msvs)

.def files get magically translated in build rules in VS, emulate that here.
Multiple .def files doesn't make any sense, and is explicitly disallowed.

Also add support for exe exports to msvs generator.

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1294 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: support running actions under cygwin shell

Primarily:
- Convert path variables to /, but only if the action is run under cygwin
- Wrap the command invocation in "variable setting + bash -c" as expected by the cygwin-friendly actions.

msvs_cygwin_dirs and msvs_cygwin_shell are non_configuration_keys, meaning they shouldn't be based on the config, so copy those global variables from the msvs generator at CalculateVariables time so that they appear in the correct location when gyp loads the input files.

Also, expand some custom VS macros command line arguments in the body of rules.

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1295 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: add support and test for linker OutputFile setting

Redirects final binary, including support for VS macros in the filename. Note that modifying the output path of a .lib isn't supported. Chromium doesn't use that because it wouldn't be dependencies-uponable anyway then.

(Depends on http://codereview.chromium.org/9923025/ being landed.)

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1296 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: filter out /MP option

Having/not having this flag doesn't change behaviour in our case, because it
only applies to multiple .cc per invocation (which we don't do), however /MP
is incompatible with some options (specifically /showIncludes) which we use
for dependency tracking.

Ninja handles managing of parallelism anyway, so it's better not to have the
toolchain forking too.

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1297 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: (internal) make include handling more link library handling

Minor cleanup, makes include handling the same style as library handling is on mac & win.

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1298 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: suppress 'Creating library...' output

A common noisy message that messes with one-line-ninja-overprinting style.

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1299 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: simpler link-wrapper code

(already reviewed/suggested in previous CL)

TBR=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1300 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: make pdb named per target by default, rather than per .cc file

Reduces memory usage during final link, but otherwise doesn't change behaviour.

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1301 78cadc50-ecff-11dd-a971-7dbc132099af
revert r1300 (returncode incorrect for link-wrapper)

TBR=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1302 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: fix pdb name fom r1301

And add assert to WriteVariableList because I seem to do that every time I use
it.

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1303 78cadc50-ecff-11dd-a971-7dbc132099af
Regression tests for Info.plists with LD_DYLIB_INSTALL_NAME.

When LD_DYLIB_INSTALL_NAME is set explicitly to $(bla:standardizepath)
in a bundle target with an Info.plist file, then DYLIB_INSTALL_NAME_BASE
gets incorrectly exported to the environment with ninja: Due to the
:standardizepath bit, it's not recognized as a variable, so ninja
passes $() on to the shell, which then tries to run that as a command.

BUG=chromium:113918
Review URL: https://chromiumcodereview.appspot.com/9980014

git-svn-id: http://gyp.googlecode.com/svn/trunk@1304 78cadc50-ecff-11dd-a971-7dbc132099af
ninja/mac: Don't export the environment twice to postbuilds.
Review URL: https://chromiumcodereview.appspot.com/10008016

git-svn-id: http://gyp.googlecode.com/svn/trunk@1305 78cadc50-ecff-11dd-a971-7dbc132099af
Export LD_DYLIB_INSTALL_NAME and DYLIB_INSTALL_NAME_BASE to postbuilds.

Also fix a bug where they didn't get exporte correctly to plists
in make and ninja.

BUG=chromium:113918
Review URL: https://chromiumcodereview.appspot.com/10005013

git-svn-id: http://gyp.googlecode.com/svn/trunk@1306 78cadc50-ecff-11dd-a971-7dbc132099af
Fixes red gypbot at r1297. gyp-win32 failing on this test on some VMs but not others (yuck!).

The root cause is that there's something slightly broken in dependency checking, either in ninja or (maybe more likely?) in the accuracy of the timestamps when relocate()ing source trees on the VMs that break.

This test shouldn't ever actually need to execute its rules (the outputs aren't actually output from a tool; there's no command line that's actually run). As such, the msvs_cygwin_dirs wasn't even specified in the test. So when the dependency check fails and the tool is run, the cygwin setup script is run an has the wrong path, so the test fails.

This patch simply specifies the correct path to cygwin, so that if it *does* run, it works correctly (and does nothing).

Future further investigation required to determine whether ninja or the VM or is actually at fault.

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1307 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: Support magic idl build rules

Magically build .idl files via midl compiler if there's no other explicit
build rule specified. Sort of 'works', but there's no edge between the
generated .h file and .cc files that might include it, so parallelism will
break it.

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1308 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: refactor libpath extraction to be shared between link and lib

Happens to fix that link path weren't relative-ized to .gyp file (but lib ones were) which is the test change.

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1309 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: support vs macro expansion in rules

Some Windows build rules use gyp magic names, and VS macros in their inputs
and outputs. Expand those as necessary.

This exposed some nastiness specifically related to $(OutputDir). For a
compile/link rule, the tool is run from the output directory, so $(OutDir) can
just be removed. For actions though, we change the working directory to the
base dir (rather than the build dir), so OutDir has to converted to point back
to the build dir, only in that case. Using an absolute path would be easier,
but ninja doesn't like abspaths (specifically the :s).

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1310 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: env refactor fixes

(and unrelatedly, add assert to ExpandMacros)

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1311 78cadc50-ecff-11dd-a971-7dbc132099af
ninja windows: add support for $(ProjectName) macro

Renames other VS macro test to more general different directory.

(Along with a couple minor CLs on Chromium .gyp files, chrome.exe/dll now links
via ninja!)

R=thakis@chromium.org

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

git-svn-id: http://gyp.googlecode.com/svn/trunk@1312 78cadc50-ecff-11dd-a971-7dbc132099af
ninja and make/mac: Fix postbuild paths.

Xcode and make treat them as relative to the gyp directory,
ninja should too.

The straightforward fix would be to call
gyp_path_to_build_path on all shell_list entries in
GetSpecPostbuildCommands(), but that would transform
non-filename strings as well. Instead, execute postbuilds
in the path the gyp file is in, like it's done for actions.
This seems to match what Xcode does.

(Note that this doesn't change the working directory for implicit
postbuilds that are inserted for stripping / dsymutil. Even though
these share an environment with the explicit postbuilds, this works
because the environment contains absolute paths for all the paths
it it.)

BUG=chromium:118873
Review URL: https://chromiumcodereview.appspot.com/10016001

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