Add installer. gyp targets: gcapi_dll, gcapi_lib, gcapi_test,...

Add installer. gyp targets: gcapi_dll, gcapi_lib, gcapi_test,
installer_unittests, installer_util, mini_installer, mini_installer_test,
setup.
Added msvs_guid settings for all targets.
Moved some variables that are used by multiple targets
to the top level.
BUG=none
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=17044

[sgk, 2009-05-27 02:44:41]

This gets them all minimally building.  Execution and verification of comparable
sizes will follow.

[bradn, 2009-05-27 17:18:31]

LGTM

[Mark Mentovai, 2009-05-27 17:26:19]

LG otherwise

http://codereview.chromium.org/115810/diff/1/2
File chrome/installer/installer.gyp (right):

http://codereview.chromium.org/115810/diff/1/2#newcode42
Line 42: 'target_name': 'gcapi_test',
Seems weird to bring in both the _dll and the _lib.  How are we positive that
the bits of the test that want to use the _lib (call_statically) are actually
being resolved to the _lib at link time and not the _dll?  The test doesn't seem
to make it explicit, and in GYP, adding the gcapi_dll dependency will cause
gcapi_test to link against both the _lib and _dll, right?

[sgk, 2009-05-27 21:02:30]

http://codereview.chromium.org/115810/diff/1/2
File chrome/installer/installer.gyp (right):

http://codereview.chromium.org/115810/diff/1/2#newcode42
Line 42: 'target_name': 'gcapi_test',
On 2009/05/27 17:26:19, Mark Mentovai wrote:
> Seems weird to bring in both the _dll and the _lib.  How are we positive that
> the bits of the test that want to use the _lib (call_statically) are actually
> being resolved to the _lib at link time and not the _dll?  The test doesn't
seem
> to make it explicit, and in GYP, adding the gcapi_dll dependency will cause
> gcapi_test to link against both the _lib and _dll, right?

This duplicates the current behavior as best as I know how in gyp.

I checked with rahulk; the goal here is one executable that tests both the
build-time symbols (chrome_lib.lib) and the run-time symbols (which the test
.exe explicitly loads from chrome_dll.dll).  In Visual Studio, we distinguished
between the link-time dependency on the .lib (which was expressed in the link in
the .vcproj file) and the run-time dependency on the .dll (an order-only
dependency expressed in the .sln file, which just made sure that the .dll was
built if you were building the test .exe).

Gyp's 'dependencies' list here isn't fine-grained about this distinction, being
the mechanism for both the make-sure-it's built ordering and the inclusion of
the library in the build.

Personally, I'd probably find it safer to refactor the .exe so that it builds
two separate test executables (one for .lib and one for.dll) from the same input
source file.

Suggestions?