clang: Enable using a different compiler path for standalone webkit make builds.

build/common.gypi

 # 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.
 
 # 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 2526 matching lines @@
     }],
     ['clang==1', {
       'make_global_settings': [
         ['CC', 'third_party/llvm-build/Release+Asserts/bin/clang'],
         ['CXX', 'third_party/llvm-build/Release+Asserts/bin/clang++'],
         ['LINK', '$(CXX)'],
         ['CC.host', '$(CC)'],
         ['CXX.host', '$(CXX)'],
         ['LINK.host', '$(LINK)'],
       ],
+      'conditions': [
+        ['inside_chromium_build==0', {

[Mark Mentovai, 2011/10/20 13:28:57]

What else sets this variable?

You’re using it to mean “is this a WebKit standalone?” which means that either
you’re not accounting for non-WebKit non-“inside_chromium” builds, or that this
variable is named unfortunately.

What sets inside_chromium_build in a WebKit standalone build? Is that a better
place to set the compiler path?

[Nico, 2011/10/20 14:36:55]

It's named unfortunately, no other build sets it.

http://codesearch.google.com/codesearch#search/&exact_package=chromium&q=insi...
 It's set in third_party/WebKit/Source/WebKit/chromium/gyp_webkit. Setting the
compiler path there is a much better idea. That way the gyp change isn't needed
either. Thanks for the suggestion!

+          'make_global_settings': [
+            # Fix up the paths to work in a stand-alone webkit checkout.
+            ['CC', 'Source/WebKit/chromium/third_party/llvm-build/Release+Asserts/bin/clang'],
+            ['CXX', 'Source/WebKit/chromium/third_party/llvm-build/Release+Asserts/bin/clang++'],
+          ],
+        }],
+      ],
     }],
   ],
   'xcode_settings': {
     # DON'T ADD ANYTHING NEW TO THIS BLOCK UNLESS YOU REALLY REALLY NEED IT!
     # This block adds *project-wide* configuration settings to each project
     # file.  It's almost always wrong to put things here.  Specify your
     # custom xcode_settings in target_defaults to add them to targets instead.
 
     # In an Xcode Project Info window, the "Base SDK for All Configurations"
     # setting sets the SDK on a project-wide basis.  In order to get the
     # configured SDK to show properly in the Xcode UI, SDKROOT must be set
     # here at the project level.
     'SDKROOT': 'macosx<(mac_sdk)',  # -isysroot
 
     # 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',
   },
 }