clang: Instead of having update.sh clobber out/, add a define with the current revision.

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 2298 matching lines @@
         'xcode_settings': {
           'DYLIB_INSTALL_NAME_BASE': '@rpath',
           'LD_RUNPATH_SEARCH_PATHS': [
             # For unbundled binaries.
             '@loader_path/.',
             # For bundled binaries, to get back from Binary.app/Contents/MacOS.
             '@loader_path/../../..',
           ],
         },
       }],
+      ['clang==1 and OS!="win"', {
+        # This is here so that all files get recompiled after a clang roll and
+        # when turning clang on or off.
+        # (defines are passed via the command line, and build systems rebuild
+        # things when their commandline changes). Nothing should ever read this
+        # define.
+        'defines': ['CR_CLANG_REVISION=<!(<(DEPTH)/tools/clang/scripts/update.sh --print-revision)'],

[hans, 2014/05/08 20:11:21]

Could we just shell out to clang and ask it which version it is?

[Nico, 2014/05/08 20:17:29]

Since --version prints 3 lines, it'd require some sed'ing, and I don't like sed
calls in gyp files, so I'd have to write a script for that. So this seems
simpler. (Also, once everything is on update.py, this could use pymod_do_main).

+      }],
       ['enable_rlz==1', {
         'defines': ['ENABLE_RLZ'],
       }],
       ['component=="shared_library"', {
         'defines': ['COMPONENT_BUILD'],
       }],
       ['toolkit_views==1', {
         'defines': ['TOOLKIT_VIEWS=1'],
       }],
       ['ui_compositor_image_transport==1', {
@@ skipping 2917 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',
   },
 }