Move closure_blocks_leopard_compat to base now that it's used by two modules.

base/base.gyp

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 {
   'variables': {
     'chromium_code': 1,
   },
   'includes': [
     '../build/win_precompile.gypi',
@@ skipping 148 matching lines @@
         'i18n/string_search_unittest.cc',
         'i18n/time_formatting_unittest.cc',
         'json/json_reader_unittest.cc',
         'json/json_value_converter_unittest.cc',
         'json/json_value_serializer_unittest.cc',
         'json/json_writer_unittest.cc',
         'json/string_escape_unittest.cc',
         'lazy_instance_unittest.cc',
         'linked_list_unittest.cc',
         'logging_unittest.cc',
+        'mac/closure_blocks_leopard_compat_unittest.cc',
         'mac/foundation_util_unittest.mm',
         'mac/mac_util_unittest.mm',
         'mac/objc_property_releaser_unittest.mm',
         'mac/scoped_sending_event_unittest.mm',
         'md5_unittest.cc',
         'memory/aligned_memory_unittest.cc',
         'memory/linked_ptr_unittest.cc',
         'memory/mru_cache_unittest.cc',
         'memory/ref_counted_memory_unittest.cc',
         'memory/ref_counted_unittest.cc',
@@ skipping 169 matching lines @@
           ],
           'sources/': [
             ['exclude', '^win/'],
           ],
           'sources!': [
             'debug/trace_event_win_unittest.cc',
             'time_win_unittest.cc',
             'win/win_util_unittest.cc',
           ],
         }],
+        ['OS=="mac"', {
+          'dependencies': [
+            'closure_blocks_leopard_compat',

[Mark Mentovai, 2012/03/01 01:25:11]

I'd rather just make the targets that need it depend on
base.gyp:closure_blocks_leopard_compat. base doesn't need it, and you've already
set the dependency properly on the other targets that do need it.

[jam, 2012/03/01 01:27:20]

this is for base_unittests. won't that need it for the test?

+          ],
+        }],
       ],
     },
     {
       'target_name': 'check_example',
       'type': 'executable',
       'sources': [
         'check_example.cc',
       ],
       'dependencies': [
         'base',
@@ skipping 88 matching lines @@
             #   base/test/perf_test_suite.h
             #   base/test/test_suite.h
             #   gtk/gtk.h
             '../build/linux/system.gyp:gtk',
           ],
         }],
       ],
     },
   ],
   'conditions': [
-    [ 'OS == "win"', {
+    ['OS == "win"', {
       'targets': [
         {
           'target_name': 'debug_message',
           'type': 'executable',
           'sources': [
             'debug_message.cc',
           ],
           'msvs_settings': {
             'VCLinkerTool': {
               'SubSystem': '2',         # Set /SUBSYSTEM:WINDOWS
             },
           },
         },
       ],
     }],
+    ['OS=="mac"', {
+     'targets': [
+       {
+         'target_name': 'closure_blocks_leopard_compat',
+         'sources': [
+           'mac/closure_blocks_leopard_compat.h',
+         ],
+         'conditions': [
+           ['mac_sdk == "10.5"', {
+             'type': 'shared_library',
+             'product_name': 'closure_blocks_leopard_compat_stub',
+             'variables': {
+               # This target controls stripping directly. See below.
+               'mac_strip': 0,
+             },
+             'sources': [
+               'mac/closure_blocks_leopard_compat.S',
+             ],
+             'xcode_settings': {
+               # These values are taken from libSystem.dylib in the 10.5
+               # SDK. Setting LD_DYLIB_INSTALL_NAME causes anything linked
+               # against this stub library to look for the symbols it
+               # provides in the real libSystem at runtime. When using ld
+               # from Xcode 4 or later (ld64-123.2 and up), giving two
+               # libraries with the same "install name" to the linker will
+               # cause it to print "ld: warning: dylibs with same install
+               # name". This is harmless, and ld will behave as intended
+               # here.
+               #
+               # The real library's compatibility version is used, and the
+               # value of the current version from the SDK is used to make
+               # it appear as though anything linked against this stub was
+               # linked against the real thing.
+               'LD_DYLIB_INSTALL_NAME': '/usr/lib/libSystem.B.dylib',
+               'DYLIB_COMPATIBILITY_VERSION': '1.0.0',
+               'DYLIB_CURRENT_VERSION': '111.1.4',
+
+               # Turn on stripping (yes, even in debug mode), and add the -c
+               # flag. This is what produces a stub library (MH_DYLIB_STUB)
+               # as opposed to a dylib (MH_DYLIB). MH_DYLIB_STUB files
+               # contain symbol tables and everything else needed for
+               # linking, but are stripped of section contents. This is the
+               # same way that the stub libraries in Mac OS X SDKs are
+               # created. dyld will refuse to load a stub library, so this
+               # provides some insurance in case anyone tries to load the
+               # stub at runtime.
+               'DEPLOYMENT_POSTPROCESSING': 'YES',
+               'STRIP_STYLE': 'non-global',
+               'STRIPFLAGS': '-c',
+             },
+           }, {  # else: mac_sdk != "10.5"
+             # When using the 10.6 SDK or newer, the necessary definitions
+             # are already present in libSystem.dylib. There is no need to
+             # build a stub dylib to provide these symbols at link time.
+             # This target is still useful to cause those symbols to be
+             # treated as weak imports in dependents, who still must
+             # #include closure_blocks_leopard_compat.h to get weak imports.
+             'type': 'none',
+           }],
+         ],
+       },
+     ],
+   }],
   ],
 }