Implement an infrastructure of Blink-in-JS

Source/build/scripts/make_private_script_source.py

Index: Source/build/scripts/make_private_script_source.py
diff --git a/Source/build/scripts/make_private_script_source.py b/Source/build/scripts/make_private_script_source.py
new file mode 100644
index 0000000000000000000000000000000000000000..1770b758270f41d7815c4c00ffb5645812e203cf
--- /dev/null
+++ b/Source/build/scripts/make_private_script_source.py
@@ -0,0 +1,38 @@
+# Copyright 2014 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.
+
+"""Convert Blink-in-JS sources to C++ constant strings.

[Nils Barth (inactive), 2014/06/23 03:14:30]

abarth@: should this be using GRIT or the like for resources?

This script is simple enough, but would be clearer as a simple Jinja template.

More importantly, we've generally preferred to have these as resources,
rather than build scripts.
abarth@ or Nico should be able to assist.
https://code.google.com/p/grit-i18n/wiki/GritUsersGuide

[haraken, 2014/06/23 06:01:46]

That's a good point. At the moment I just added a FIXME to rewrite the script to
grit. If I should rewrite it to grit in this CL, I'll do that. Otherwise, I want
to do that after landing Blink-in-JS's infrastructure.

[Nils Barth (inactive), 2014/06/23 06:21:25]

Might be ok to do later, but would be better to do sooner.

You should ask abarth: he's been reluctant to accept this sort of added build
script,
and if you're going to have to include JS as resources somewhere *anyway*
(regardless
of how the rest of Blink-in-JS is actually implemented), it doesn't hurt to do
it now rather
than later.

OTOH, if this is really in flux and you don't want to figure out GRIT *now*,
should be ok to do later.

Anyway, do ask abarth@ on this point.

+
+Usage:
+python make_private_script.py DESTINATION_FILE SOURCE_FILES
+"""
+
+import os
+import sys
+
+
+def main():
+    output_filename = sys.argv[1]
+    input_filenames = sys.argv[2:]
+    contents = ''

[Nils Barth (inactive), 2014/06/23 03:14:30]

FWIW, in Python generally it's preferred to build a string by building a list
and then using string.join(), or using StringIO (cStringIO),
as simple implementations of string += are O(n^2)
(b/c strings are immutable and thus this builds a new string at each
concatenation).

This is optimized in CPython 2.5+, so this *should* be ok and not a bottleneck,
and you are using join for the key part, but a heads-up about possible build
performance issues.

+    for input_filename in input_filenames:
+        class_name, ext = os.path.splitext(os.path.basename(input_filename))
+        with open(input_filename) as input_file:
+            input_text = input_file.read()
+            hex_values = ['0x{0:02x}'.format(ord(char)) for char in input_text]
+            contents += 'const unsigned char kSourceOf%s[] = {\n    %s\n};\n' % (
+                class_name, ', '.join(hex_values))
+    contents += '\nstruct PrivateScriptSources {\n    const char* name;\n    const unsigned char* source;\n    size_t size;\n};\n\n'

[Nils Barth (inactive), 2014/06/23 03:14:30]

This would be rather clearer as a multiline string """

+    contents += 'struct PrivateScriptSources kPrivateScriptSources[] = {\n'
+    for input_filename in input_filenames:
+        class_name, ext = os.path.splitext(os.path.basename(input_filename))
+        contents += '    { "%s", kSourceOf%s, sizeof(kSourceOf%s) },\n' % (class_name, class_name, class_name)
+    contents += '};\n'
+
+    with open(output_filename, 'w') as output_file:
+        output_file.write(contents)
+
+
+if __name__ == '__main__':
+    sys.exit(main())