Allow use of ^blocks, even with the 10.5 SDK, and even with a 10.5 runtime

chrome/browser/mac/closure_leopard_compat/closure_leopard_compat.gyp

Index: chrome/browser/mac/closure_leopard_compat/closure_leopard_compat.gyp
===================================================================
--- chrome/browser/mac/closure_leopard_compat/closure_leopard_compat.gyp	(revision 0)
+++ chrome/browser/mac/closure_leopard_compat/closure_leopard_compat.gyp	(revision 0)
@@ -0,0 +1,85 @@
+# Copyright (c) 2011 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.
+
+# libclosure (blocks) compatibilty for Mac OS X 10.5 (Leopard)
+#
+# Background material:
+# http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Blocks
+# http://opensource.apple.com/source/libclosure/libclosure-38/
+#
+# Leopard doesn't support blocks. Chrome supports Leopard. Chrome needs to use
+# blocks.
+#
+# In any file where you use blocks (any time you type ^{...}), you must
+# #include block.h (in this directory) to ensure that the runtime symbols
+# used by libclosure are marked for weak-import. This means that if these
+# symbols are not present at runtime, the program will still load, but their
+# values will be NULL.
+#
+# In any target (in the GYP sense) where you use blocks, you must depend on
+# the closure_leopard_compat target (in this file) to ensure that these
+# symbols will be available at link time, even when the 10.5 SDK is in use.
+# This allows the continued use of the 10.5 SDK.
+#
+# This does not relieve you of the responsibility to not use blocks on
+# Leopard. Because runtime support for Blocks still isn't present on that
+# operating system, the weak-imported symbols will have value 0 and attempts
+# to do anything meaningful with them will fail or crash. You must take care
+# not to enter any block-using codepath on Leopard. The base::mac::IsOS*
+# family may be helpful.
+
+{
+  'variables': {
+    'chromium_code': 1,
+  },
+  'targets': [
+    {
+      'target_name': 'closure_leopard_compat',
+      'conditions': [
+        ['mac_sdk == "10.5"', {
+          'type': 'shared_library',
+          'product_name': 'closure_leopard_compat_stub',
+          'sources': [
+            'definitions.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. 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',

[Mark Mentovai, 2011/08/08 18:30:21]

Nico: FYI: The Mac make generator will need to support this. I’m not sure if it
does yet.

+            '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 provide 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.
+          'type': 'none',
+        }],
+      ],
+      'direct_dependent_settings': {
+        'include_dirs': [
+          'include',
+        ],
+      },
+    },
+  ],
+}
Property changes on: chrome/browser/mac/closure_leopard_compat/closure_leopard_compat.gyp
___________________________________________________________________
Added: svn:eol-style
   + LF