Trigger some java_apk.gypi actions for all builds

Trigger some java_apk.gypi actions for all builds

This adds a fake output path to several actions in java_apk.gypi:
push_libraries
apk_install
strip_libraries (when component==shared_library)

Adding this fake output makes the build system think that these actions
always need to be run when building the corresponding APK (because the fake
output is never up-to-date).

For the first two actions, this is required to ensure that (when
gyp_managed_install==1) the APK on the device (and its libraries) are
always up-to-date. If a user switches the connected device, then these
actions must be run even if no files on the host changed.

For strip_libraries, we do not know at gyp-time what the real inputs to
the action are (i.e. all the library dependencies). Also, ninja does
some build magic such that if you change a library (base.so for example)
its dependencies will not necessarily change.

BUG=158821
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=193518

[Yaron, 2013-04-04 20:24:23]

It's a shame to have to do this, but I don't know of another way. It seems like
it's abusing gyp but I guess having a managed install is a little different.
Does this mean that you'll never see the ninja "no work to do"?

Let's hold off on landing this until all steps have the right up-to-date checks.

https://codereview.chromium.org/13599002/diff/2001/build/java_apk.gypi
File build/java_apk.gypi (right):

https://codereview.chromium.org/13599002/diff/2001/build/java_apk.gypi#newcod...
build/java_apk.gypi:135: # Add a fake output to force the build to always re-run
this step. This
Can you inline this like the other variables? Nicer to have the explanation
right in the outputs step, and it doesn't look like this is re-used anywhere.
Oh, this was done so that it's only conditionally executed, right? I think we
should only do this if we're doing a managed install. I can imagine thaat at
least at first our components bots won't use managed install.

[cjhopman, 2013-04-04 21:13:13]

On 2013/04/04 20:24:23, Yaron wrote:
> It's a shame to have to do this, but I don't know of another way. It seems
like
> it's abusing gyp but I guess having a managed install is a little different.

Yeah, it is somewhat abusive (though it isn't exploiting the particular
gyp/generator implementation). It's important, though, that builds are correct.

One approach that would allow ninja to say "no work to do", would be to have a
trigger_file as input to these actions, and then wrap ninja in a script that
touched that trigger_file when the device changed (or when it detects that an
apk was installed on the device outside of the gyp_managed_install). With such a
detector, the first step would be to add that trigger file and have a target
that runs the detector and then all these targets could depend on it.

> Does this mean that you'll never see the ninja "no work to do"?

Correct.

> 
> Let's hold off on landing this until all steps have the right up-to-date
checks.

sgtm.

[cjhopman, 2013-04-04 21:13:19]

https://codereview.chromium.org/13599002/diff/2001/build/java_apk.gypi
File build/java_apk.gypi (right):

https://codereview.chromium.org/13599002/diff/2001/build/java_apk.gypi#newcod...
build/java_apk.gypi:135: # Add a fake output to force the build to always re-run
this step. This
On 2013/04/04 20:24:23, Yaron wrote:
> Can you inline this like the other variables? Nicer to have the explanation
> right in the outputs step, and it doesn't look like this is re-used anywhere.
> Oh, this was done so that it's only conditionally executed, right? I think we
> should only do this if we're doing a managed install. I can imagine thaat at
> least at first our components bots won't use managed install.

This one has run even if it isn't a managed_install. The strip step is used for
all builds (that have native libraries) and for the component build we can't
specify the correct inputs.

It is added here because it is only needed in the component build, not the
non-component build.

[cjhopman, 2013-04-10 19:04:42]

yfriedman: ping

[Yaron, 2013-04-10 20:37:13]

lgtm

https://codereview.chromium.org/13599002/diff/2001/build/java_apk.gypi
File build/java_apk.gypi (right):

https://codereview.chromium.org/13599002/diff/2001/build/java_apk.gypi#newcod...
build/java_apk.gypi:135: # Add a fake output to force the build to always re-run
this step. This
On 2013/04/04 21:13:19, cjhopman wrote:
> On 2013/04/04 20:24:23, Yaron wrote:
> > Can you inline this like the other variables? Nicer to have the explanation
> > right in the outputs step, and it doesn't look like this is re-used
anywhere.
> > Oh, this was done so that it's only conditionally executed, right? I think
we
> > should only do this if we're doing a managed install. I can imagine thaat at
> > least at first our components bots won't use managed install.
> 
> This one has run even if it isn't a managed_install. The strip step is used
for
> all builds (that have native libraries) and for the component build we can't
> specify the correct inputs.
> 
> It is added here because it is only needed in the component build, not the
> non-component build.

Can you file/link to a bug to remove this when it can be known at gyp time?

[commit-bot: I haz the power, 2013-04-10 22:14:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/cjhopman@chromium.org/13599002/15001

[commit-bot: I haz the power, 2013-04-10 22:22:39]

Sorry for I got bad news for ya.
Compile failed with a clobber build on android_clang_dbg.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_cl...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-04-10 22:25:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/cjhopman@chromium.org/13599002/20002

[commit-bot: I haz the power, 2013-04-11 00:26:26]

Change committed as 193518