build/java_cpp_template.gypi: new build rules.

build/java_cpp_template.gypi

+# 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.

[Ryan Sleevi, 2012/12/04 03:14:56]

This should be in build/android, given that it depends on a particular
compiler/toolchain (line 67-72)

[digit1, 2012/12/04 12:20:34]

I can move it there, but we already have plenty of other .gypi files under
build/ that are in the same case, that's why I thought it was the natural
location for this file.

+#
+# 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': [
+    {
+      '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', '<(DEPTH)',      # Add project top-level to include path
+        '-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,

[Ryan Sleevi, 2012/12/04 03:14:56]

Why 'process_outputs_as_sources', given that there is no .java rule here?

Your canonical example in 13-24 indicates that this should be a whole target,
but process_outputs_as_sources is only necessary if this .gypi will be included
in non-"none" targets, right?

[digit1, 2012/12/04 12:20:34]

The NetError.template generates an output named NetError.java, I believe this is
necessary to ensure that the latter is considered a proper source during the
build. (Inspired from from build/jni_gnerator.gypi which does the reverse, i.e.
generate C++ headers and sources from Java files).
I'm not too familiar with the terminology used here :) I essentially imitated
what's in jni_generator.gypi. What would be your recommendation to fix this?

+    }
+  ],
+  'hard_dependency': 1,

[Ryan Sleevi, 2012/12/04 03:14:56]

hard_dependency is only applicable to static_library, which I understand no java
target will ever be, right?

So why this directive?

[digit1, 2012/12/04 12:20:34]

It also came from jni_generator.gypi, I'll remove it.

+}