Adds -Wno-deprecated-register to the build settings for iOS.

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 4445 matching lines @@
           'CLANG_WARN_OBJC_MISSING_PROPERTY_SYNTHESIS': 'YES',
           'WARNING_CFLAGS': [
             '-Wheader-hygiene',
             # Don't die on dtoa code that uses a char as an array index.
             # This is required solely for base/third_party/dmg_fp/dtoa.cc.
             '-Wno-char-subscripts',
             # See comment in the mac clang section above for this flag.
             '-Wno-unneeded-internal-declaration',
             # Match OS X clang C++11 warning settings.
             '-Wno-c++11-narrowing',
+            # As of Xcode 5.1, the register keyword is deprecated, but Chromium
+            # code still uses it.
+            '-Wno-deprecated-register',

[rohitrao (ping after 24h), 2014/03/11 21:09:39]

-Wno-deprecated-register is now passed *twice* for iOS ninja builds.  It's added
once in the "mac or ios, clang==1" section above, and a second time here.

Is this a big deal?  The alternative is to conditionally add it in the iOS block
if ("<(GENERATOR)"=="xcode").

(Do we still support building Mac with Xcode?  Could we just unconditionally add
-Wno-deprecated-register and break Xcode builds, or would that make people mad?

[Mark Mentovai, 2014/03/11 21:39:52]

rohitrao wrote:
I’m taking that to mean that you’re not always using clang? Really?

[rohitrao (ping after 24h), 2014/03/11 21:49:31]

"clang==1" is only true if you're using Ninja.  It's false for Xcode builds. 
Most developers are on ninja by now, but the bots (and official builders) are
still using Xcode.

Xcode itself is using clang too, but that doesn't mean "clang==1" =)

[Mark Mentovai, 2014/03/11 21:55:46]

rohitrao wrote:
That sounds wrongish to me.

If you’re using clang everywhere, can you set clang=1 even in your Xcode builds?

           ],
 
           # Limit the valid architectures depending on "target_subarch".

[Mark Mentovai, 2014/03/11 21:39:52]

This comment goes with the target_subarch conditions that were already there,
but now you’ve separated them.

[rohitrao (ping after 24h), 2014/03/11 21:49:31]

Done.

           # This need to include the "arm" architectures but also the "x86"
           # ones (they are used when building for the simulator).
           'conditions': [
+            # Older Xcodes do not support -Wno-deprecated-register, so pass an
+            # additional flag to suppress the "unknown compiler option" error.
+            # Restrict this flag to builds that are either compiling with Xcode
+            # or compiling with Xcode's Clang.  This will allow Ninja builds to
+            # continue failing on unknown compiler options.
+            # TODO(rohitrao): This flag is temporary and should be removed as
+            # soon as the iOS bots are updated to use Xcode 5.1.
+            ['"<(GENERATOR)"=="xcode" or clang_xcode==1', {
+              'WARNING_CFLAGS': [
+                '-Wno-unknown-warning-option',
+              ],
+            }],
             ['target_subarch=="arm32"', {
               'VALID_ARCHS': ['armv7', 'i386'],
             }],
             ['target_subarch=="arm64"', {
               'VALID_ARCHS': ['arm64', 'x86_64'],
             }],
             ['target_subarch=="both"', {
               'VALID_ARCHS': ['arm64', 'armv7', 'x86_64', 'i386'],
             }],
           ],
@@ skipping 570 matching lines @@
     # 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',
   },
 }