[iOS] Add assert_no_deps to //build/config/ios/rules.gni "app" template.

[iOS] Add assert_no_deps to //build/config/ios/rules.gni "app" template.

The "assert_no_deps" stops recursion at Target::EXECUTABLE, so for the
moment add the assertion to "app" template "executable" target so that
they are correctly evaluated for all target build on iOS.

BUG=459705

[sdefresne, 2016-03-15 14:55:40]

sdefresne@chromium.org changed reviewers:
+ brettw@chromium.org

[sdefresne, 2016-03-15 14:55:41]

I do not really like putting the assert_no_deps and would prefer to put it in
//BUILD.gn, but this does not work as it stops at Target::EXECUTABLE.

WDYT?

[brettw, 2016-03-15 18:04:17]

https://codereview.chromium.org/1801083002/diff/20001/build/config/ios/rules.gni
File build/config/ios/rules.gni (right):

https://codereview.chromium.org/1801083002/diff/20001/build/config/ios/rules....
build/config/ios/rules.gni:116: assert_no_deps = [
I think we should forward this from the invoker to the executable target here
and then the app declaration itself can decide what it depends on.

[sdefresne, 2016-03-16 16:53:26]

On 2016/03/15 at 18:04:17, brettw wrote:
>
https://codereview.chromium.org/1801083002/diff/20001/build/config/ios/rules.gni
> File build/config/ios/rules.gni (right):
> 
>
https://codereview.chromium.org/1801083002/diff/20001/build/config/ios/rules....
> build/config/ios/rules.gni:116: assert_no_deps = [
> I think we should forward this from the invoker to the executable target here
and then the app declaration itself can decide what it depends on.

Well, the problem with forwarding from the invoker is that it needs to be added
per app. However the restriction on //content, //ipc, ... need to be enforced
for all iOS app. If I leave it to the developer adding a new app then I do not
expect it to be properly maintained (few people outside of members of the Chrome
on iOS team know the restrictions that are imposed on iOS).

This is why, as I've said in the gn-dev thread, I would have like to be able to
set an assert_no_deps to //:gn_all target (which is sadly not working
currently). Maybe I should just change this to:

if (!defined(assert_no_deps)) {
  assert_no_deps = []
}
assert_no_deps += [
  "//content/*",
  ...
]

WDYT?

[brettw, 2016-03-16 17:13:31]

Yeah, I try really hard not to mention things like content in the shared build
directory, and from a build perspective I think it's wrong to say nobody can
create an iOS app that uses "X" (for any value of "X") without forking the build
setup.

At the end of the day, I think there's only one app that matters about these
dependencies and that's Chrome (I think). It will be pretty hard to make, say,
some test project depend on content but not iOS Chrome depend on content. If
there are a couple of critical targets, we can have a list in a .gni file
somewhere and just set that variable as the assert_no_deps on those targets,
since our list of targets is mostly static.

[sdefresne, 2016-03-16 17:47:15]

On 2016/03/16 at 17:13:31, brettw wrote:
> Yeah, I try really hard not to mention things like content in the shared build
directory, and from a build perspective I think it's wrong to say nobody can
create an iOS app that uses "X" (for any value of "X") without forking the build
setup.
> 
> At the end of the day, I think there's only one app that matters about these
dependencies and that's Chrome (I think). It will be pretty hard to make, say,
some test project depend on content but not iOS Chrome depend on content. If
there are a couple of critical targets, we can have a list in a .gni file
somewhere and just set that variable as the assert_no_deps on those targets,
since our list of targets is mostly static.

Well, components_unittests comes to mind (it's been frequently plagued by
submarine new dependencies on //content). I've also seen new dependencies on
//ipc added to //ui/base:unittests. I guess I'll go with the list in a .gni file
and adding the assert_no_deps to apps that we do care on iOS (mostly the apps
listed in ios/build/bots/tests/common_tests.json).

Thank you for the recommendations. Will close this CL and create a new one along
those.