Adding base_untrusted.

base/base.gyp

Index: base/base.gyp
diff --git a/base/base.gyp b/base/base.gyp
index 72bfdc67843fcb8d5115a60551aee319e7381d0d..63982ce006c47392bba0e230a2abb55957abe73c 100644
--- a/base/base.gyp
+++ b/base/base.gyp
@@ -8,6 +8,7 @@
   },
   'includes': [
     '../build/win_precompile.gypi',
+    '../native_client/build/untrusted.gypi',

[brettw, 2012/06/04 19:20:51]

Various other components like some random ChromeOS daemon pull and use base.
While I don't know how all of these work, I'd imagine that adding this line
would cause them to break since they'd need a NaCl checkout.

Is it possible to have something that we can define to enable this dependency so
people that don't define this don't need to have nacl checked out?

     'base.gypi',
   ],
   'targets': [
@@ -582,41 +583,41 @@
       ],
     }],
     ['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',
+      '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)
@@ -665,7 +666,31 @@
             'input_jars_paths': ['<(PRODUCT_DIR)/lib.java/chromium_base.jar',],
           },
           'includes': [ '../build/apk_test.gypi' ],
-        }],
+        },
+      ],
+    }],
+    ['disable_nacl_untrusted==0', {
+      'targets': [
+        {
+          'target_name': 'base_untrusted',
+          'type': 'none',
+          'variables': {
+            'base_target': 1,
+            'nacl_untrusted_build': 1,
+            'nlib_target': 'libbase_untrusted.a',
+            'build_glibc': 0,
+            'build_newlib': 1,
+          },
+          'sources!': [
+            'file_util.cc',
+          ],
+          'dependencies': [
+            '<(DEPTH)/native_client/tools.gyp:prep_toolchain',
+            '<(DEPTH)/native_client/src/untrusted/pthread/pthread.gyp:pthread_lib',
+            '<(DEPTH)/native_client/src/untrusted/nacl/nacl.gyp:nacl_lib_newlib',
+          ],
+        },
+      ],
     }],
   ],
 }