Support target/host architecture with ninja iOS builds

build/common.gypi

 # 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.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 1282 matching lines @@
         'use_system_sqlite%': 0,  # '<(android_webview_build)',
         'use_system_expat%': '<(android_webview_build)',
         'use_system_icu%': '<(android_webview_build)',
         'use_system_stlport%': '<(android_webview_build)',
 
         'enable_managed_users%': 0,
 
         # Copy it out one scope.
         'android_webview_build%': '<(android_webview_build)',
       }],  # OS=="android"
-      ['OS=="mac"', {
+      ['OS=="mac" or OS=="ios"', {
         'variables': {
           # Mac OS X SDK and deployment target support.  The SDK identifies
           # the version of the system headers that will be used, and
           # corresponds to the MAC_OS_X_VERSION_MAX_ALLOWED compile-time
           # macro.  "Maximum allowed" refers to the operating system version
           # whose APIs are available in the headers.  The deployment target
           # identifies the minimum system version that the built products are
           # expected to function on.  It corresponds to the
           # MAC_OS_X_VERSION_MIN_REQUIRED compile-time macro.  To ensure these
           # macros are available, #include <AvailabilityMacros.h>.  Additional
@@ skipping 12 matching lines @@
           'mac_sdk_min%': '10.6',
           'mac_sdk_path%': '',
 
           'mac_deployment_target%': '10.6',
         },
 
         'mac_sdk_min': '<(mac_sdk_min)',
         'mac_sdk_path': '<(mac_sdk_path)',
         'mac_deployment_target': '<(mac_deployment_target)',
 
-        # Enable clang on mac by default!
-        'clang%': 1,
+        'conditions': [

[stuartmorgan, 2013/05/07 13:14:46]

Probably clearer if you just make the mac section a sibling of the mac || ios
section instead of nesting it like this. Or are there variable scoping issues
with that?

[justincohen, 2013/05/07 14:50:57]

Yeah, it ended up looking like this because of var scoping.

On 2013/05/07 13:14:46, stuartmorgan wrote:

+          ['OS=="mac"', {
+            # Enable clang on mac by default!
+            'clang%': 1,
 
-        # Compile in Breakpad support by default so that it can be
-        # tested, even if it is not enabled by default at runtime.
-        'mac_breakpad_compiled_in%': 1,
-        'conditions': [
-          # mac_product_name is set to the name of the .app bundle as it should
-          # appear on disk.  This duplicates data from
-          # chrome/app/theme/chromium/BRANDING and
-          # chrome/app/theme/google_chrome/BRANDING, but is necessary to get
-          # these names into the build system.
-          ['branding=="Chrome"', {
-            'mac_product_name%': 'Google Chrome',
-          }, { # else: branding!="Chrome"
-            'mac_product_name%': 'Chromium',
-          }],
+            # Compile in Breakpad support by default so that it can be
+            # tested, even if it is not enabled by default at runtime.
+            'mac_breakpad_compiled_in%': 1,
+            'conditions': [
+              # mac_product_name is set to the name of the .app bundle as it should
+              # appear on disk.  This duplicates data from
+              # chrome/app/theme/chromium/BRANDING and
+              # chrome/app/theme/google_chrome/BRANDING, but is necessary to get
+              # these names into the build system.
+              ['branding=="Chrome"', {
+                'mac_product_name%': 'Google Chrome',
+              }, { # else: branding!="Chrome"
+                'mac_product_name%': 'Chromium',
+              }],
 
-          ['branding=="Chrome" and buildtype=="Official"', {
-            'mac_sdk%': '<!(python <(DEPTH)/build/mac/find_sdk.py --verify <(mac_sdk_min) --sdk_path=<(mac_sdk_path))',
-            # Enable uploading crash dumps.
-            'mac_breakpad_uploads%': 1,
-            # Enable dumping symbols at build time for use by Mac Breakpad.
-            'mac_breakpad%': 1,
-            # Enable Keystone auto-update support.
-            'mac_keystone%': 1,
-          }, { # else: branding!="Chrome" or buildtype!="Official"
-            'mac_sdk%': '<!(python <(DEPTH)/build/mac/find_sdk.py <(mac_sdk_min))',
-            'mac_breakpad_uploads%': 0,
-            'mac_breakpad%': 0,
-            'mac_keystone%': 0,
+              ['branding=="Chrome" and buildtype=="Official"', {
+                'mac_sdk%': '<!(python <(DEPTH)/build/mac/find_sdk.py --verify <(mac_sdk_min) --sdk_path=<(mac_sdk_path))',
+                # Enable uploading crash dumps.
+                'mac_breakpad_uploads%': 1,
+                # Enable dumping symbols at build time for use by Mac Breakpad.
+                'mac_breakpad%': 1,
+                # Enable Keystone auto-update support.
+                'mac_keystone%': 1,
+              }, { # else: branding!="Chrome" or buildtype!="Official"
+                'mac_sdk%': '<!(python <(DEPTH)/build/mac/find_sdk.py <(mac_sdk_min))',
+                'mac_breakpad_uploads%': 0,
+                'mac_breakpad%': 0,
+                'mac_keystone%': 0,
+              }],
+            ],
           }],
         ],
       }],  # OS=="mac"

[stuartmorgan, 2013/05/07 13:14:46]

If you do have to keep the nested structure for variables, fix this comment, and
add a closing comment to the new Mac block.

[justincohen, 2013/05/07 14:50:57]

Done.

       ['OS=="win"', {
         'conditions': [
           ['component=="shared_library"', {
             'win_use_allocator_shim%': 0,
           }],
           ['component=="shared_library" and "<(GENERATOR)"=="ninja"', {
             # Only enabled by default for ninja because it's buggy in VS.
             # Not enabled for component=static_library because some targets
             # are too large and the toolchain fails due to the size of the
             # .obj files.
@@ skipping 1681 matching lines @@
               # See the comment in the Mac section for what it takes to move
               # this to -std=c++11.
               '-std=gnu++11',
             ],
           }],
           ['clang==1 and (OS=="android" or chromeos==1)', {
             # Android uses gcc4.4, and clang isn't compatible with gcc4.4's
             # libstdc++ in C++11 mode. So no C++11 mode for Android yet.
             # Doesn't work with asan for some reason either: crbug.com/233464
             'cflags': [
-              # Especially needed for gtest macros using enum values from Mac   
-              # system headers. 
-              # TODO(pkasting): In C++11 this is legal, so this should be       
-              # removed when we change to that.  (This is also why we don't     
-              # bother fixing all these cases today.)   
-              '-Wno-unnamed-type-template-args',        
-              # This (rightfully) complains about 'override', which we use      
-              # heavily.        
+              # Especially needed for gtest macros using enum values from Mac
+              # system headers.
+              # TODO(pkasting): In C++11 this is legal, so this should be
+              # removed when we change to that.  (This is also why we don't
+              # bother fixing all these cases today.)
+              '-Wno-unnamed-type-template-args',
+              # This (rightfully) complains about 'override', which we use
+              # heavily.
               '-Wno-c++11-extensions',
             ],
           }],
           ['clang==1 and clang_use_chrome_plugins==1', {
             'cflags': [
               '<@(clang_chrome_plugins_flags)',
             ],
           }],
           ['clang==1 and clang_load!=""', {
             'cflags': [
@@ skipping 922 matching lines @@
             # Clang spots more unused functions.
             '-Wno-unused-function',
             # See comments on this flag higher up in this file.
             '-Wno-unnamed-type-template-args',
             # This (rightfully) complains about 'override', which we use
             # heavily.
             '-Wno-c++11-extensions',
           ],
         },
         'target_conditions': [
+          ['_toolset=="host"', {
+            'xcode_settings': {
+              'SDKROOT': 'macosx<(mac_sdk)',  # -isysroot
+              'MACOSX_DEPLOYMENT_TARGET': '<(mac_deployment_target)',
+            },
+          }],
+          ['_toolset=="target"', {
+            'xcode_settings': {
+              'IPHONEOS_DEPLOYMENT_TARGET': '<(ios_deployment_target)',
+            },
+          }],
           ['_type=="executable"', {
             'configurations': {
               'Release_Base': {
                 'xcode_settings': {
                   'DEPLOYMENT_POSTPROCESSING': 'YES',
                   'STRIP_INSTALLED_PRODUCT': 'YES',
                 },
               },
               'Debug_Base': {
                 'xcode_settings': {
@@ skipping 383 matching lines @@
             ],
           }, {
             'SDKROOT': '<(ios_sdk_path)',  # -isysroot
           }],
         ],
       }],
       ['OS=="ios"', {
         'ARCHS': '$(ARCHS_UNIVERSAL_IPHONE_OS)',
         # Just build armv7, until armv7s is correctly tested.
         'VALID_ARCHS': 'armv7 i386',
-        'IPHONEOS_DEPLOYMENT_TARGET': '<(ios_deployment_target)',
         # Target both iPhone and iPad.
         'TARGETED_DEVICE_FAMILY': '1,2',
       }],
       ['target_arch=="x64"', {
         'ARCHS': [
           'x86_64'
          ],
       }],
     ],
 
     # The Xcode generator will look for an xcode_settings section at the root
     # of each dict and use it to apply settings on a file-wide basis.  Most
     # settings should not be here, they should be in target-specific
     # xcode_settings sections, or better yet, should use non-Xcode-specific
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }