build/java_cpp_template.gypi: new build rules.

build/java_cpp_template.gypi

Index: build/java_cpp_template.gypi
diff --git a/build/java_cpp_template.gypi b/build/java_cpp_template.gypi
new file mode 100644
index 0000000000000000000000000000000000000000..9dc7603834c3a605015b29dde47b373c11bbd1de
--- /dev/null
+++ b/build/java_cpp_template.gypi
@@ -0,0 +1,77 @@
+# 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.
+
+# This file is meant to be included into a target to provide a rule
+# to generate Java source files from templates that are processed
+# through the host C pre-processor.
+#
+# This assumes a GNU-compatible pre-processor installed as 'cpp'.
+# Only tested on Linux.
+#
+# To use this, create a gyp target with the following form:
+#  {
+#    'target_name': 'android_net_java_constants',
+#    'type': 'none',
+#    'sources': [
+#      'net/base/certificate_mime_type_list.h',
+#      'net/android/NetError.template',
+#    ],
+#    'variables': {
+#      'package_name': 'org.chromium.net',
+#    },
+#    'includes': [ '../build/java_constants.gypi' ],
+#  },
+#
+# The 'sources' entry should list all input files. The template file
+# itself should use the 'ClassName.template' format, and will generate
+# 'gen/templates/<package-name>/ClassName.java. Other source files
+# are those typically included by the template. Any change to them
+# will force a rebuild of the template, and hence of any source that
+# depends on it.
+#
+
+{
+  # Location where all generated Java sources will be placed.
+  'variables': {
+    'output_dir': '<(SHARED_INTERMEDIATE_DIR)/templates/<(package_name)'
+  },
+  # Ensure that the output directory is used in the class path
+  # when building targets that depend on this one.
+  'direct_dependent_settings': {
+    'variables': {
+      'generated_src_dirs': [
+        '<(output_dir)/',
+      ],
+    },
+  },
+  # Define a single rule that will be apply to each .template file
+  # listed in 'sources'.
+  'rules': [{

[bulach, 2012/11/27 17:57:12]

my understanding is that "rules" are used to map 1:1 a list of inputs to its
output.. for instance, the jni_generator takes a list of .java, and then for
each one, it generates a header file..

since this takes a pair of files (the template and the header), I think it's
better suited as an "action" (see build/java.gypi versus
build/jni_generator.gypi, and
http://code.google.com/p/gyp/wiki/GypLanguageSpecification)

[digit1, 2012/11/27 22:29:07]

Hi Marcus, I think a 'rules' section is appropriate and more elegant here. Let
me explain:

Each rule inside a 'rules' directive only takes files from 'sources' filtered by
their extension. This means that if you list both a header and a template, only
the template (i.e. the file in sources that ends with '.template') will be
considered for the generate_java_constants rule below.

Also, 'rules' give you RULE_INPUT_ROOT, which makes the ClassName.template ->
ClassName.java transformation trivial. You can't do it in an 'actions' block, so
you end up having to hard-code both the template name and output file name in
the caller (this is what the original net/net.gyp did).

[bulach, 2012/11/28 08:57:30]

oh, you're right, thanks for the detailed explanation! I didn't know the
"extension" was a filtering condition..

+    'rule_name': 'generate_java_constants',
+    'extension': 'template',
+     # Ensure the generated Java file is treated as input to the targets
+     # that depend on it.
+    'direct_dependent_settings': {
+      'variables': {
+        'additional_input_paths': [
+          '<(output_dir)/<(RULE_INPUT_ROOT).java'
+        ],
+      },
+    },
+    'outputs': [
+      '<(output_dir)/<(RULE_INPUT_ROOT).java'
+    ],
+    'action': [
+      'cpp',  # invoke host pre-processor.
+      '-x', 'c-header',  # treat sources as C header files
+      '-P',   # disable line markers, i.e. '#line 309'
+      '-I', '..',  # Add project top-level to include path

[digit1, 2012/11/28 10:58:48]

I wonder if we shouldn't use <(DEPTH) instead here. I'm not sure what this
variable does, even after reading the Gyp documentation. Any opinion?

+      '-o', '<@(_outputs)',   # Specify output file
+      '<(RULE_INPUT_PATH)',  # Specify input file
+    ],
+    'message': 'Generating Java from cpp template <(RULE_INPUT_PATH)',
+    'process_outputs_as_sources': 1,
+  }],
+  'hard_dependency': 1,
+}