Initial implementation of Chrome Early Loading Framework

chrome_elf/chrome_elf.gypi

+{

[grt (UTC plus 2), 2013/11/06 19:07:29]

now that chrome_elf is its own top-level dir, i think this should become
chrome_elf.gyp rather than a .gypi file only relevant within the context of
chrome.gyp. see, for example, net/net.gyp, base/base.gyp, content/content.gyp.

[grt (UTC plus 2), 2013/11/06 19:07:29]

# Copyright 2013 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.

[Cait (Slow), 2013/11/06 21:18:06]

Done.

[Cait (Slow), 2013/11/06 21:18:06]

Done.

+

[grt (UTC plus 2), 2013/11/06 19:07:29]

remove spurious blank line

[Cait (Slow), 2013/11/06 21:18:06]

Done.

+  'includes': [
+    '../chrome/version.gypi',
+  ],
+  'targets': [
+    {
+      'target_name': 'chrome_elf',
+      'type': 'shared_library',
+      'include_dirs': [
+        '..',
+      ],
+      'sources': [
+        'chrome_elf.def',
+        'chrome_elf_main.cc',
+        'chrome_elf_main.h',
+      ],
+      'actions' :  [
+        { # Construct a manifest file declaring chrome.exe's dependency on
+          # chrome_elf.dll. This will be embedded in chrome.exe when it is
+          # built.

[gab, 2013/11/06 16:07:25]

s/This will be embedded in chrome.exe when it is built./This will be merged into
chrome.exe.manifest and embedded into chrome.exe when it is built.

[Cait (Slow), 2013/11/06 21:18:06]

Done.

+          'action_name': 'chrome_exe_manifest',
+          'variables': {
+            'template_input_path':
+                'chrome_exe_manifest.template',
+          },
+          'inputs': [
+            '<(template_input_path)',
+            '<(version_path)',
+          ],
+          'outputs': [
+            '<(SHARED_INTERMEDIATE_DIR)/chrome_elf/version_assembly.manifest',
+          ],
+          'action': [
+            'python', '<(version_py_path)',
+            '-f', '<(version_path)',
+            '<(template_input_path)',
+            '<@(_outputs)',
+          ],
+          'message': 'Generating <@(_outputs)'
+        },
+        { # Construct a manifest file (with the same name as the version_dir) so
+          # that chrome.exe identifies the version_dir as an assembly. This will
+          # be copied over to the version_dir by the installer script.
+          'action_name': 'version_assembly_manifest',
+          'variables': {
+            'template_input_path':
+                'version_assembly_manifest.template',
+          },
+          'inputs': [
+            '<(template_input_path)',
+            '<(version_path)',

[gab, 2013/11/06 16:07:25]

Should <(version_full) be an input here? What about <(version_py_path)?

[Cait (Slow), 2013/11/06 21:18:06]

For reference:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/version.gypi

version_py_path is the path to chrome/tools/build/version.py (the script that
we're passing the inputs to).
version_path is the path to chrome/VERSION which stores current version info
(version.py takes this file as input)
version_full is a string containing the current versionin
MAJOR.MINOR.BUILD.PATCH form (I only use it for the manifest name).

The 'inputs' section does seem a bit redundant though. It might be possible to
either just pass '<@(_inputs)' to version_py_path, or remove the 'inputs'
section altogether, and just pass in the variables -- I'll look into that.

+          ],
+          'outputs': [
+            '<(PRODUCT_DIR)/<(version_full).manifest',
+          ],
+          'action': [
+            'python', '<(version_py_path)',
+            '-f', '<(version_path)',
+            '<(template_input_path)',
+            '<@(_outputs)',
+          ],
+          'message': 'Generating <@(_outputs)'
+        },
+      ],
+    },
+  ],
+}