Mac coverage fix to mirror the Mac valgrind fix.

BUG=none
TEST=none

Review URL: http://codereview.chromium.org/2037007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46985 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 18 insertions, 16 deletions

diff --git a/chrome/chrome_tests.gypi b/chrome/chrome_tests.gypi
index d0a35cb..f69922c 100644
--- a/chrome/chrome_tests.gypi
+++ b/chrome/chrome_tests.gypi
@@ -1124,23 +1124,25 @@
           # other things like the ui, startup, and page_cycler tests. *shrug*
           'xcode_settings': {'OTHER_LDFLAGS': ['-Wl,-ObjC']},
 
-          # The Mac Valgrind build uses compilation settings that cause its
-          # code size to swell more than any other build. In particular,
-          # libwebcore.a is so large that ld may not have a sufficiently large
-          # "hole" in its address space into which it can be mmaped by the
-          # time it reaches this library. As of May 10, 2010, libwebcore.a is
-          # 1023MB in this build. In the Mac OS X 10.5 toolchain, using Xcode
-          # 3.1, ld is only a 32-bit executable, and address space exhaustion
-          # is the result, with ld failing and producing the message:
+          # The Mac Valgrind and Coverage builds use compilation
+          # settings that cause their code size to swell more than any
+          # other build. In particular, libwebcore.a is so large that
+          # ld may not have a sufficiently large "hole" in its address
+          # space into which it can be mmaped by the time it reaches
+          # this library. As of May 10, 2010, libwebcore.a is 1023MB
+          # in this build. In the Mac OS X 10.5 toolchain, using Xcode
+          # 3.1, ld is only a 32-bit executable, and address space
+          # exhaustion is the result, with ld failing and producing
+          # the message:
           # ld: in .../libwebcore.a, can't map file, errno=12
           #
-          # As a workaround, in the Mac Valgrind build, ensure that
-          # libwebcore.a appears to ld first when linking unit_tests. This
-          # allows the library to be mmaped when ld's address space is "wide
-          # open." Other libraries are small enough that they'll be able to
-          # "squeeze" into the remaining holes. The Mac linker isn't so
-          # sensitive that moving this library to the front of the list will
-          # cause problems.
+          # As a workaround, in these builds, ensure that libwebcore.a
+          # appears to ld first when linking unit_tests. This allows
+          # the library to be mmaped when ld's address space is "wide
+          # open." Other libraries are small enough that they'll be
+          # able to "squeeze" into the remaining holes. The Mac linker
+          # isn't so sensitive that moving this library to the front
+          # of the list will cause problems.
           'variables': {
             # release_valgrind_build may not be defined at this point, so
             # provide a default definition here (matching the one in
@@ -1148,7 +1150,7 @@
             'release_valgrind_build%': 0,
           },
           'conditions': [
-            ['release_valgrind_build==1', {
+            ['release_valgrind_build==1 or coverage==1', {
               # Enough pluses to make get this target prepended to the
               # target's list of dependencies.
               'dependencies+++': [