Initial implementation of Chrome Early Loading Framework

chrome_elf/version_assembly_manifest_action.gypi

Index: chrome_elf/version_assembly_manifest_action.gypi
diff --git a/chrome_elf/version_assembly_manifest_action.gypi b/chrome_elf/version_assembly_manifest_action.gypi
new file mode 100644
index 0000000000000000000000000000000000000000..43543e39eb0fc8a52a5b2347f8524b593ef7113b
--- /dev/null
+++ b/chrome_elf/version_assembly_manifest_action.gypi
@@ -0,0 +1,37 @@
+# Copyright 2013 The Chromium Authors. All rights reserved.

[gab, 2013/11/11 20:11:38]

This isn't really chrome_elf specific (beyond the fact that for now this
assembly is only used to pull chrome_elf.dll).

I feel this should live in chrome_exe land (i.e., it's not more chrome_elf'ish
than the dependency of chrome_exe on chrome_elf itself).

Should we want to add another DLL to the list of assemblies, if it's here we'll
have to move it, if it's in chrome we'll just have to add that DLL to the files
in the template.


The same is true for the other manifest, to be embedded in chrome.exe, which is
even less chrome_elf specific.

I would put the manifests+templates+gyp actions+README all in their own
directory, probably under chrome/, e.g. chrome/version_assembly (I don't have a
good enough knowledge of the logic behind the chrome/ layout to know exactly
where it should fit, but something like that).

[Cait (Slow), 2013/11/12 16:33:54]

From discussing with grt, I have a follow up patch I'm working on to tidy up how
and when these manifests are created (and generalize the actions a bit). Are you
ok with these changes being incorporated into that patch?

[gab, 2013/11/12 18:24:10]

What's that plan? It feels weird to dump everything here just to move it all to
another directory late, but I could be convinced about this CL as a temporary
step in a clear long-term plan (with TODOs for the remaining work in this CL).

+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+# This file contains an action which can be used to construct a manifest file
+# with the same name as the version directory so that chrome.exe identifies the
+# version directory as an assembly. This will be copied over to the version
+# directory by the installer script.
+
+# To use this the following variables need to be defined:
+#   version_path: string: path to file containing version data (e.g.
+#                 chrome/VERSION).
+#   version_py_path: string: path to file containing version script (e.g.
+#                    chrome/tools/build/version.py).
+#   version_full: string: version string in WWWW.X.YYYY.Z form.

[gab, 2013/11/11 20:11:38]

Why WWWW.X.YYYY.Z? Nothing prevents X/Z to be more than 1 char AFAIK (I sure
know Z has been 2 chars in many cases I've seen). Nor, does W/Y have to be 4
chars.

I'd just say "W.X.Y.Z form".

[Cait (Slow), 2013/11/12 16:33:54]

Done.

+
+
+{
+  'variables': {
+    'template_input_path':
+        '<(DEPTH)/chrome_elf/version_assembly_manifest.template',
+  },
+  'inputs': [
+    '<(template_input_path)',
+    '<(version_path)',
+  ],
+  'outputs': [
+    '<(PRODUCT_DIR)/<(version_full).manifest',
+  ],
+  'action': [
+    'python', '<(version_py_path)',
+    '-f', '<(version_path)',
+    '<(template_input_path)',
+    '<@(_outputs)',
+  ],
+  'message': 'Generating <@(_outputs)',
+}