Add templates for building java and running the jni_generator.

build/jni_generator.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 jni bindings for Java-files in a consistent manner.
+#
+# To use this, create a gyp target with the following form:
+# {
+#   'target_name': 'base_jni_headers',
+#   'type': 'none',
+#   'variables': {
+#       'java_sources': [
+#         'android/java/org/chromium/base/BuildInfo.java',
+#         'android/java/org/chromium/base/PathUtils.java',
+#         'android/java/org/chromium/base/SystemMessageHandler.java',
+#       ],
+#       'jni_headers': [
+#         '<(SHARED_INTERMEDIATE_DIR)/base/jni/build_info_jni.h',
+#         '<(SHARED_INTERMEDIATE_DIR)/base/jni/path_utils_jni.h',
+#         '<(SHARED_INTERMEDIATE_DIR)/base/jni/system_message_handler_jni.h',
+#       ],
+#   },
+#   'includes': [ '../build/jni_generator.gypi' ],
+# }
+#
+# The ordering of the java_sources must match the ordering of jni_headers. The
+# result is that for each Java file listed in java_sources, the corresponding
+# entry in jni_headers contains the JNI bindings produced from running the
+# jni_generator on the input file.
+#
+# See base/android/jni_generator/jni_generator.py for more info about the
+# format of generating JNI bindings.
+
+{
+  'actions': [
+      {
+        'action_name': 'generate_jni_headers',
+        'type': 'none',
+        'inputs': [
+          '<(DEPTH)/base/android/jni_generator/jni_generator.py',

[Ryan Sleevi, 2012/04/14 03:10:50]

I wonder if this should be under
build/android

rather than
base/android...

The use of <(DEPTH) here and on line 49 are correct, though, since you're
wanting to explicitly reference a (non-"user"-input) file in a .gypi

[Yaron, 2012/04/16 20:44:56]

I'm kinda ambivalent about whether it's in base or build. My only concern would
be possibly deps but I guess we can whitelist it if there any issues. Also, I'd
have to update media in this same patch. Do you want me to do that here or do
those as a separate patch?

[Ryan Sleevi, 2012/04/16 21:03:00]

I'm fine with either approach if you do update.

+          '<@(java_sources)',
+        ],
+        'outputs': [
+          '<@(jni_headers)',

[Ryan Sleevi, 2012/04/14 03:10:50]

Are the JNI header names deterministic? Just wondering if this could be done as
a 'rule' rather than an 'action', which would save you from having to add
'jni_headers' everywhere - as well as being able to use <(RULE_INPUT_PATH) and
such

[Yaron, 2012/04/16 20:44:56]

Downstream I think there are a few exceptions but I don't believe that's for any
particularly good reason. Is there an existing function I can use to convert the
filenames or are you suggesting that these headers would have non-standard
naming (i.e. BuildInfoJni_h)?

[Ryan Sleevi, 2012/04/16 21:03:00]

Ah, right, using <(RULE_INPUT_ROOT) with BuildInfo.java would yield
BuildInfoJni.h, rather than build_info_jni.h as desired.

One further though/suggestion, if you think there will be a lot of JNI
generation, you may wish to look into the pymod_do_main support of GYP. Rather
than shelling out and then invoking Python, you can run the module command
inline during the GYP phase. This was added for Grit, which was a noticable part
of gclient sync'ing, but can easily be re-used. See src/build/grit_action.gypi
for how this is accomplished.

[Yaron, 2012/04/16 21:15:32]

I'm wondering if this merits an exception in the style guide. It seems like it
would be some indication that it's auto-generated and it would make gyp less
verbose. In the app-part of our code theres' on the order of 40 of these files
so it'd help. Who makes a call like this?

[Yaron, 2012/04/16 21:21:23]

Oh and as for the pymod_do_main part of your comment.. That would mean that a
change to a java file that affects jni generation would have to re-gyp, right?

[Ryan Sleevi, 2012/04/16 21:25:05]

Mark and/or chromium-dev.

So far our rules have lucked out in that only the extension changes, and the
input filenames match the desired Chromium naming scheme (.idl for Windows, for
example)

[Ryan Sleevi, 2012/04/16 21:25:05]

Yes. However, with the use of wildcard expansion for the Java compilation, isn't
that somewhat true already?

+        ],
+        'action': [
+          'python',
+          '<(DEPTH)/base/android/jni_generator/jni_generator.py',
+          '-o',
+          '<@(_inputs)',
+          '<@(_outputs)',
+        ],
+      },
+  ],
+}