Add missing android files to GN runtime_deps

Add missing android files to GN runtime_deps

BUG=589318

[agrieve, 2016-03-09 02:50:52]

agrieve@chromium.org changed reviewers:
+ brettw@chromium.org, dpranke@chromium.org

[agrieve, 2016-03-09 02:50:53]

I'm not happy with having to create separate __data targets, but I couldn't
figure out how to prevent group()s from having their data included by dependants
(e.g. they are included even when using dep, instead of only when using data_dep
/ public_dep).

There is at least one target (//clank/android_webview:platform_bridge_assets)
that includes an .apk as a build-time dep and not a data dep, and I don't want
apks to unconditionally have all dependants consider it a data_dep.

Is there a better way?

This seems also to be a problem with the .so file that gets packed into the
.apk. The shared_library() is only even included via deps = [], but it's showing
up in the .isolate. Is there a way to have it not considered a runtime_dep?

[Dirk Pranke, 2016-03-09 03:20:08]

I'm afraid I am totally lost on this CL. I don't understand what problem you're
hitting, nor how you're trying to solve it.

Can you attempt to restate what you wrote in comment #2 so that people who are
less familiar with all the
apk building/packaging steps can understand what's going on better, since I've
pretty much purged all of this
from my head?

I think maybe you're hitting some variant of the issue in bug 536289, where we
talk about how runtime_deps
are supposed to be calculated and how the dependencies of an executable do not
propagate into the
runtime dependencies of things that depend on the executable at build time. 

Maybe you need something similar for apks in some situations, but I don't know
how you can have one 
apk depend on another apk as a build-time dependency (i.e., I didn't know that
was possible or what 
that would mean?).

[agrieve, 2016-03-09 15:26:43]

On 2016/03/09 03:20:08, Dirk Pranke wrote:
> I'm afraid I am totally lost on this CL. I don't understand what problem
you're
> hitting, nor how you're trying to solve it.
> 
> Can you attempt to restate what you wrote in comment #2 so that people who are
> less familiar with all the
> apk building/packaging steps can understand what's going on better, since I've
> pretty much purged all of this
> from my head?

Let's try again:
1. I'm trying to get android_apk() to behave like executable() when it comes to
runtime_deps. I'd like it so that if you depend on it via deps, then it's not in
your runtime deps, but if you depend on it via data_deps, then it is.

2. I never want an apk's .so to be included in runtime_deps. It's only ever a
build-time dep. I can't figure out how to prevent it from being included.


> 
> I think maybe you're hitting some variant of the issue in bug 536289, where we
> talk about how runtime_deps
> are supposed to be calculated and how the dependencies of an executable do not
> propagate into the
> runtime dependencies of things that depend on the executable at build time. 

That's a bit ironic - my problem is that I can't get a group to *stop*
propagating data. Perhaps it's because it's group()s all the way down? (querying
for runtime_deps of a group(), that just depends on other groups())


> 
> Maybe you need something similar for apks in some situations, but I don't know
> how you can have one 
> apk depend on another apk as a build-time dependency (i.e., I didn't know that
> was possible or what 
> that would mean?).
This is the only case I found, but it's a case where one apk is being included
as an android_asset() of another. If there's no easy work-around, I'll just
change this so that .apk is always a runtime_dep() and live with it being
included where it shouldn't be in one place.

[agrieve, 2016-03-09 19:07:07]

To fix bots, going to go ahead with: https://codereview.chromium.org/1774193004/

I'm still very interested in this discussion though, as there are other files in
the .isolate that shouldn't be there (I'll file a separate bug for that).

On 2016/03/09 15:26:43, agrieve wrote:
> On 2016/03/09 03:20:08, Dirk Pranke wrote:
> > I'm afraid I am totally lost on this CL. I don't understand what problem
> you're
> > hitting, nor how you're trying to solve it.
> > 
> > Can you attempt to restate what you wrote in comment #2 so that people who
are
> > less familiar with all the
> > apk building/packaging steps can understand what's going on better, since
I've
> > pretty much purged all of this
> > from my head?
> 
> Let's try again:
> 1. I'm trying to get android_apk() to behave like executable() when it comes
to
> runtime_deps. I'd like it so that if you depend on it via deps, then it's not
in
> your runtime deps, but if you depend on it via data_deps, then it is.
> 
> 2. I never want an apk's .so to be included in runtime_deps. It's only ever a
> build-time dep. I can't figure out how to prevent it from being included.
> 
> 
> > 
> > I think maybe you're hitting some variant of the issue in bug 536289, where
we
> > talk about how runtime_deps
> > are supposed to be calculated and how the dependencies of an executable do
not
> > propagate into the
> > runtime dependencies of things that depend on the executable at build time. 
> 
> That's a bit ironic - my problem is that I can't get a group to *stop*
> propagating data. Perhaps it's because it's group()s all the way down?
(querying
> for runtime_deps of a group(), that just depends on other groups())
> 
> 
> > 
> > Maybe you need something similar for apks in some situations, but I don't
know
> > how you can have one 
> > apk depend on another apk as a build-time dependency (i.e., I didn't know
that
> > was possible or what 
> > that would mean?).
> This is the only case I found, but it's a case where one apk is being included
> as an android_asset() of another. If there's no easy work-around, I'll just
> change this so that .apk is always a runtime_dep() and live with it being
> included where it shouldn't be in one place.

[agrieve, 2016-03-09 19:19:41]

On 2016/03/09 19:07:07, agrieve wrote:
> To fix bots, going to go ahead with:
https://codereview.chromium.org/1774193004/
> 
> I'm still very interested in this discussion though, as there are other files
in
> the .isolate that shouldn't be there (I'll file a separate bug for that).
https://bugs.chromium.org/p/chromium/issues/detail?id=593416

> 
> On 2016/03/09 15:26:43, agrieve wrote:
> > On 2016/03/09 03:20:08, Dirk Pranke wrote:
> > > I'm afraid I am totally lost on this CL. I don't understand what problem
> > you're
> > > hitting, nor how you're trying to solve it.
> > > 
> > > Can you attempt to restate what you wrote in comment #2 so that people who
> are
> > > less familiar with all the
> > > apk building/packaging steps can understand what's going on better, since
> I've
> > > pretty much purged all of this
> > > from my head?
> > 
> > Let's try again:
> > 1. I'm trying to get android_apk() to behave like executable() when it comes
> to
> > runtime_deps. I'd like it so that if you depend on it via deps, then it's
not
> in
> > your runtime deps, but if you depend on it via data_deps, then it is.
> > 
> > 2. I never want an apk's .so to be included in runtime_deps. It's only ever
a
> > build-time dep. I can't figure out how to prevent it from being included.
> > 
> > 
> > > 
> > > I think maybe you're hitting some variant of the issue in bug 536289,
where
> we
> > > talk about how runtime_deps
> > > are supposed to be calculated and how the dependencies of an executable do
> not
> > > propagate into the
> > > runtime dependencies of things that depend on the executable at build
time. 
> > 
> > That's a bit ironic - my problem is that I can't get a group to *stop*
> > propagating data. Perhaps it's because it's group()s all the way down?
> (querying
> > for runtime_deps of a group(), that just depends on other groups())
> > 
> > 
> > > 
> > > Maybe you need something similar for apks in some situations, but I don't
> know
> > > how you can have one 
> > > apk depend on another apk as a build-time dependency (i.e., I didn't know
> that
> > > was possible or what 
> > > that would mean?).
> > This is the only case I found, but it's a case where one apk is being
included
> > as an android_asset() of another. If there's no easy work-around, I'll just
> > change this so that .apk is always a runtime_dep() and live with it being
> > included where it shouldn't be in one place.