Bring Syzygy binaries in using a script rather than as a dependency.

DEPS

 # This file is automatically processed to create .DEPS.git which is the file
 # that gclient uses under git.
 #
 # See http://code.google.com/p/chromium/wiki/UsingGit
 #
 # To test manually, run:
 #   python tools/deps2git/deps2git.py -o .DEPS.git -w <gclientdir>
 # where <gcliendir> is the absolute path to the directory containing the
 # .gclient file (the parent of "src").
 #
@@ skipping 350 matching lines @@
        Var("nacl_tools_revision")),
     # GNU binutils assembler for x86-64.
     "src/third_party/mingw-w64/mingw/bin":
       (Var("nacl_trunk") + "/deps/third_party/mingw-w64/mingw/bin@" +
        Var("nacl_tools_revision")),
 
     # Dependencies used by libjpeg-turbo
     "src/third_party/yasm/binaries":
       "/trunk/deps/third_party/yasm/binaries@154708",
 
-    # Binary level profile guided optimizations. This points to the
-    # latest release binaries for the toolchain.
-    "src/third_party/syzygy/binaries":
-      (Var("googlecode_url") % "sawbuck") + "/trunk/syzygy/binaries@2154",
-
     # Binaries for nacl sdk.
     "src/third_party/nacl_sdk_binaries":
       "/trunk/deps/third_party/nacl_sdk_binaries@111576",
   },
   "ios": {
     "src/third_party/google_toolbox_for_mac/src":
       (Var("googlecode_url") % "google-toolbox-for-mac") + "/trunk@" +
       Var("google_toolbox_for_mac_revision"),
 
     "src/third_party/nss":
@@ skipping 375 matching lines @@
     "name": "eu-strip",
     "pattern": ".",
     "action": [ "download_from_google_storage",
                 "--no_resume",
                 "--platform=linux*",
                 "--no_auth",
                 "--bucket", "chromium-eu-strip",
                 "-s", "src/build/linux/bin/eu-strip.sha1",
     ],
   },
+  # Pull the Syzygy binaries, used for optimization and instrumentation.
+  {
+    "name": "syzygy-binaries",
+    "pattern": ".",
+    "action": ["python",
+               "src/build/get_syzygy_binaries.py",
+               "--output-dir=src/third_party/syzygy/binaries",
+               "--revision=b08fb72610963d31cc3eae33f746a04e263bd860",

[Sigurður Ásgeirsson, 2014/05/28 15:24:12]

Sorry to be a ninny, but everything else above indirects the sha1 through a
file. Is there reason to do likewise here?
It's going to be much easier to review and commit a file, and this will lend
itself better to automated rolling, if ever it comes to that...

[chrisha, 2014/05/28 15:40:50]

There's no real advantage to one vs the other for us, as either way its simply
changing the value of a single hash. The other mechanisms use
download_from_google_storage, which will download foo.exe alongside an existing
foo.exe.sha1 file. Due to the sheer number of files we download and install
using this mechanism would be expensive and awkward for us (require changing
dozens of .sha1 files per roll). Instead we opted for something similar in
spirit (a script that downloads from common data storage), but that gets all the
binaries in a single go from a single specified hash.

+               "--overwrite",
+    ],
+  },
   {
     # A change to a .gyp, .gypi, or to GYP itself should run the generator.
     "name": "gyp",
     "pattern": ".",
     "action": ["python", "src/build/gyp_chromium"],
   },
 ]