Make the workaround from bug 43791 unconditional

chrome/chrome_tests.gypi

Index: chrome/chrome_tests.gypi
===================================================================
--- chrome/chrome_tests.gypi	(revision 47146)
+++ chrome/chrome_tests.gypi	(working copy)
@@ -1136,39 +1136,26 @@
           # other things like the ui, startup, and page_cycler tests. *shrug*
           'xcode_settings': {'OTHER_LDFLAGS': ['-Wl,-ObjC']},
 
-          # 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
+          # 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
+          # about 1GB in some builds. 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 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
-            # build/common.gypi).
-            'release_valgrind_build%': 0,
-          },
-          'conditions': [
-            ['release_valgrind_build==1 or coverage==1', {
-              # Enough pluses to make get this target prepended to the
-              # target's list of dependencies.
-              'dependencies+++': [
-                '../third_party/WebKit/WebCore/WebCore.gyp/WebCore.gyp:webcore',
-              ],
-            }],
+          # As a workaround, ensure that libwebcore.a appears to ld first when
+          # linking unit_tests. This allows the library to be mmapped 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.
+          #
+          # Enough pluses to make get this target prepended to the target's
+          # list of dependencies.
+          'dependencies+++': [
+            '../third_party/WebKit/WebCore/WebCore.gyp/WebCore.gyp:webcore',
           ],
         }, { # OS != "mac"
           'dependencies': [