Add templates for building java and running the jni_generator.

Add templates for building java and running the jni_generator.

As requested in http://codereview.chromium.org/10073024/, I've created
templates for these two actions. I've also applied them to base.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=132537

[Yaron, 2012-04-14 02:28:16]

mark: base/OWNERS
rsleevi: everything (you requested it :)
jrg: base/android and general approach

One point brought up in http://codereview.chromium.org/10073024/ is that we're
globbing java files instead of explicitly listing them. jrg@ and I discussed
this and we feel it's the more idiomatic approach to writing Java code. For
example, in eclipse, you don't list each Java file, you add packages and grab
all files within them.

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

So, the problem here is that this will only pick up dependencies at GYP
invocation. Any new (or removed) dependencies will not be discovered until
gclient is re-run and the appropriate build files are re-generated.

Comments below

http://codereview.chromium.org/10081035/diff/2001/base/base.gyp
File base/base.gyp (right):

http://codereview.chromium.org/10081035/diff/2001/base/base.gyp#newcode126
base/base.gyp:126: 'jni_headers': [
You will probably want to rename 'jni_headers' and 'java_sources' in order to
have the same equivalence with what you have now - but I may be wrong here.

See
http://code.google.com/p/gyp/wiki/InputFormatReference#Pathname_Relativization

http://codereview.chromium.org/10081035/diff/2001/build/java.gypi
File build/java.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/java.gypi#newcode10
build/java.gypi:10: #   'target_name': 'my-package_java',
nit: 'my-package_java' -> 'my_package_java' ?

Just wanted to confirm the '-' was intentional

http://codereview.chromium.org/10081035/diff/2001/build/java.gypi#newcode14
build/java.gypi:14: #     'java_root': 'path/to/package/root',
It seems a bit odd that this doesn't get relativized in the invoking GYP file.

That is, it seems like
foo/bar/baz/bat/cog.gyp

would need to say 'java_root' as 'foo/bar/baz/bat', due to the use of <(DEPTH)
on line 49.

You should be able to get away by changing this to

java_in_dir (note the _dir suffix), and then you could change lines 39 & 49 to
read '<(java_in_dir)/<(package_name).xml' and line 40 to read '<!@(find
<(java_in_dir) -name "*.java")'

Seems a more robust solution

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:41:
'<(DEPTH)/base/android/jni_generator/jni_generator.py',
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

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:45: '<@(jni_headers)',
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

[Mark Mentovai, 2012-04-16 15:27:37]

LG for OWNERS approval purposes only once Ryan gives the go-ahead.

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

http://codereview.chromium.org/10081035/diff/2001/base/base.gyp
File base/base.gyp (right):

http://codereview.chromium.org/10081035/diff/2001/base/base.gyp#newcode126
base/base.gyp:126: 'jni_headers': [
On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> You will probably want to rename 'jni_headers' and 'java_sources' in order to
> have the same equivalence with what you have now - but I may be wrong here.
> 
> See
> http://code.google.com/p/gyp/wiki/InputFormatReference#Pathname_Relativization


It's unnecessary because these are passed to inputs which are already
relativized

http://codereview.chromium.org/10081035/diff/2001/build/java.gypi
File build/java.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/java.gypi#newcode10
build/java.gypi:10: #   'target_name': 'my-package_java',
On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> nit: 'my-package_java' -> 'my_package_java' ?
> 
> Just wanted to confirm the '-' was intentional

Ya. I could make it package_java but I wanted to hint that _java was expected
naming.

http://codereview.chromium.org/10081035/diff/2001/build/java.gypi#newcode14
build/java.gypi:14: #     'java_root': 'path/to/package/root',
On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> It seems a bit odd that this doesn't get relativized in the invoking GYP file.
> 
> That is, it seems like
> foo/bar/baz/bat/cog.gyp
> 
> would need to say 'java_root' as 'foo/bar/baz/bat', due to the use of <(DEPTH)
> on line 49.
> 
> You should be able to get away by changing this to
> 
> java_in_dir (note the _dir suffix), and then you could change lines 39 & 49 to
> read '<(java_in_dir)/<(package_name).xml' and line 40 to read '<!@(find
> <(java_in_dir) -name "*.java")'
> 
> Seems a more robust solution 

Done.

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:41:
'<(DEPTH)/base/android/jni_generator/jni_generator.py',
On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> 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

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?

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:45: '<@(jni_headers)',
On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> 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

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]

LGTM. The wildcard expansion saddens a bit, but I suppose the Android workflow
is divergent enough that it's probably correct. If Mark's ok with that, no
objections here.

A few further comments below, but they're fine to be addressed in follow-ups (if
addressed)

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:41:
'<(DEPTH)/base/android/jni_generator/jni_generator.py',
On 2012/04/16 20:44:56, Yaron wrote:
> On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> > 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
> 
> 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?

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

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:45: '<@(jni_headers)',
On 2012/04/16 20:44:56, Yaron wrote:
> On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> > 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
> 
> 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)?

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.

http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:51: '<@(_inputs)',
Is your jni_generator.py script stripping off the first jni_generator.py from
inputs (line 41) ?

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

Mark: I think the presubmit requires an official "lgtm" from you. At least "git
cl presubmit" complains that I don't have an OWNER from base and base/android.

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:45: '<@(jni_headers)',
On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> On 2012/04/16 20:44:56, Yaron wrote:
> > On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> > > 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
> > 
> > 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)?
> 
> Ah, right, using <(RULE_INPUT_ROOT) with BuildInfo.java would yield
> BuildInfoJni.h, rather than build_info_jni.h as desired.
> 
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?

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

http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:51: '<@(_inputs)',
On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> Is your jni_generator.py script stripping off the first jni_generator.py from
> inputs (line 41) ?

Ya, it's kind of weird that it needs to be passed in. I've masked that fact
inside this template so that callers don't have to see it. We should fix it.

[Ryan Sleevi, 2012-04-16 21:21:17]

http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:51: '<@(_inputs)',
On 2012/04/16 21:15:32, Yaron wrote:
> On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> > Is your jni_generator.py script stripping off the first jni_generator.py
from
> > inputs (line 41) ?
> 
> Ya, it's kind of weird that it needs to be passed in. I've masked that fact
> inside this template so that callers don't have to see it. We should fix it.

Renaming the variables (java_sources -> java_source_files), either outside of
this template would yield the relativized paths. You would then use
<@(java_source_files) instead of <@(_inputs) here. You still leave line 41 in
place (so that this target is rebuilt if the .py changes), but the actual
invocation can use the custom name.

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

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:45: '<@(jni_headers)',
On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> On 2012/04/16 20:44:56, Yaron wrote:
> > On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> > > 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
> > 
> > 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)?
> 
> 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.

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?

[Mark Mentovai, 2012-04-16 21:23:36]

LGTM then.

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

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi
File build/jni_generator.gypi (right):

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:45: '<@(jni_headers)',
On 2012/04/16 21:15:32, Yaron wrote:
> On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> > On 2012/04/16 20:44:56, Yaron wrote:
> > > On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> > > > 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
> > > 
> > > 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)?
> > 
> > Ah, right, using <(RULE_INPUT_ROOT) with BuildInfo.java would yield
> > BuildInfoJni.h, rather than build_info_jni.h as desired.
> > 
> 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?

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)

http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#ne...
build/jni_generator.gypi:45: '<@(jni_headers)',
On 2012/04/16 21:21:23, Yaron wrote:
> On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> > On 2012/04/16 20:44:56, Yaron wrote:
> > > On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> > > > 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
> > > 
> > > 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)?
> > 
> > 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.
> 
> 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?

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

[Mark Mentovai, 2012-04-16 21:27:09]

Your output files (produced by a rule or action) don’t need their names to
follow normal_naming_conventions if it’s easier for them to follow some
other convention based on their input file names.

On Mon, Apr 16, 2012 at 5:15 PM, <yfriedman@chromium.org> wrote:

> Mark: I think the presubmit requires an official "lgtm" from you. At least
> "git
> cl presubmit" complains that I don't have an OWNER from base and
> base/android.
>
>
>
> http://codereview.chromium.**org/10081035/diff/2001/build/**
>
jni_generator.gypi<http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi>
> File build/jni_generator.gypi (right):
>
> http://codereview.chromium.**org/10081035/diff/2001/build/**
>
jni_generator.gypi#newcode45<http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#newcode45>
> build/jni_generator.gypi:45: '<@(jni_headers)',
> On 2012/04/16 21:03:00, Ryan Sleevi wrote:
>
>> On 2012/04/16 20:44:56, Yaron wrote:
>> > On 2012/04/14 03:10:50, Ryan Sleevi wrote:
>> > > 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
>> >
>> > 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)?
>>
>
>  Ah, right, using <(RULE_INPUT_ROOT) with BuildInfo.java would yield
>> BuildInfoJni.h, rather than build_info_jni.h as desired.
>>
>
> 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?
>
>
>  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.
>>
>
> http://codereview.chromium.**org/10081035/diff/6001/build/**
>
jni_generator.gypi<http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi>
> File build/jni_generator.gypi (right):
>
> http://codereview.chromium.**org/10081035/diff/6001/build/**
>
jni_generator.gypi#newcode51<http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi#newcode51>
> build/jni_generator.gypi:51: '<@(_inputs)',
> On 2012/04/16 21:03:00, Ryan Sleevi wrote:
>
>> Is your jni_generator.py script stripping off the first
>>
> jni_generator.py from
>
>> inputs (line 41) ?
>>
>
> Ya, it's kind of weird that it needs to be passed in. I've masked that
> fact inside this template so that callers don't have to see it. We
> should fix it.
>
>
http://codereview.chromium.**org/10081035/<http://codereview.chromium.org/100...
>

[Yaron, 2012-04-17 00:22:51]

On 2012/04/16 21:27:09, Mark Mentovai wrote:
> Your output files (produced by a rule or action) don’t need their names to
> follow normal_naming_conventions if it’s easier for them to follow some
> other convention based on their input file names.
> 
> On Mon, Apr 16, 2012 at 5:15 PM, <mailto:yfriedman@chromium.org> wrote:
> 
> > Mark: I think the presubmit requires an official "lgtm" from you. At least
> > "git
> > cl presubmit" complains that I don't have an OWNER from base and
> > base/android.
> >
> >
> >
> > http://codereview.chromium.**org/10081035/diff/2001/build/**
> >
>
jni_generator.gypi<http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi>
> > File build/jni_generator.gypi (right):
> >
> > http://codereview.chromium.**org/10081035/diff/2001/build/**
> >
>
jni_generator.gypi#newcode45<http://codereview.chromium.org/10081035/diff/2001/build/jni_generator.gypi#newcode45>
> > build/jni_generator.gypi:45: '<@(jni_headers)',
> > On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> >
> >> On 2012/04/16 20:44:56, Yaron wrote:
> >> > On 2012/04/14 03:10:50, Ryan Sleevi wrote:
> >> > > 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
> >> >
> >> > 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)?
> >>
> >
> >  Ah, right, using <(RULE_INPUT_ROOT) with BuildInfo.java would yield
> >> BuildInfoJni.h, rather than build_info_jni.h as desired.
> >>
> >
> > 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?
> >
> >
> >  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.
> >>
> >
> > http://codereview.chromium.**org/10081035/diff/6001/build/**
> >
>
jni_generator.gypi<http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi>
> > File build/jni_generator.gypi (right):
> >
> > http://codereview.chromium.**org/10081035/diff/6001/build/**
> >
>
jni_generator.gypi#newcode51<http://codereview.chromium.org/10081035/diff/6001/build/jni_generator.gypi#newcode51>
> > build/jni_generator.gypi:51: '<@(_inputs)',
> > On 2012/04/16 21:03:00, Ryan Sleevi wrote:
> >
> >> Is your jni_generator.py script stripping off the first
> >>
> > jni_generator.py from
> >
> >> inputs (line 41) ?
> >>
> >
> > Ya, it's kind of weird that it needs to be passed in. I've masked that
> > fact inside this template so that callers don't have to see it. We
> > should fix it.
> >
> >
>
http://codereview.chromium.**org/10081035/%3Chttp://codereview.chromium.org/1...>
> >

Ok, I like the direction we're heading. I spun off crbug.com/123718 to track
that in a separate change as it requires additional work in jni_generator. I
also want to give Marcus a chance to comment on it in case I'm missing something

[John Grabowski, 2012-04-17 01:06:29]

LGTM

Like this a lot

[commit-bot: I haz the power, 2012-04-17 01:13:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yfriedman@chromium.org/10081035/6001

[commit-bot: I haz the power, 2012-04-17 01:23:45]

Try job failure for 10081035-6001 (retry) on win for step "update".
It's a second try, previously, step "update" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...

Step "update" is always a major failure.
Look at the try server FAQ for more details.

[John Grabowski, 2012-04-17 01:46:09]

patch set 4 LGTM

[commit-bot: I haz the power, 2012-04-17 01:46:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yfriedman@chromium.org/10081035/10005

[commit-bot: I haz the power, 2012-04-17 04:39:53]

Change committed as 132537