DEPS rule to restrict ui/views dependencies in c/b/ui/cocoa

DEPS rule to restrict ui/views dependencies in c/b/ui/cocoa

Now that toolkit-views is linked in on Mac, it's possible to add
toolkit-views dependencies without an error. But code in c/b/ui/cocoa
should remain free of toolkit-views since we don't want to mix toolkits.

The exception is bridging classes that are used to integrate
toolkit-views with a Cocoa browser, but would become unnecessary in the
hypothetical world where the entire browser is tooklit-views. That is,
things in c/b/ui/cocoa shouldn't be linked in when mac_views_browser=1
in GYP_DEFINES.

BUG=425229
Committed: https://crrev.com/76e0a54543e89070695a03b83c7c7ad9f7a4edbf
Cr-Commit-Position: refs/heads/master@{#333418}

[tapted, 2015-06-04 04:07:16]

tapted@chromium.org changed reviewers:
+ thakis@chromium.org

[tapted, 2015-06-05 05:40:18]

Hi Nico, please take a look.

This is partly to dissuade things like http://crrev.com/1162393003/ (i.e. we
shouldn't pull views dependencies into code that doesn't need it).

It also gives "bridging" classes in c/b/ui/cocoa access to c/b/ui/views which
they don't currently have -- i.e. let code for the Cocoa browser that wants to
surface views UI permission, but make it be explicit about it by putting "views"
in the filename (an example of this is http://crrev.com/1167883002 i.e. the
"chrome_app_window_client_views_cocoa.mm" there).

Thanks!

[Nico, 2015-06-05 06:29:43]

lgtm

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/DEPS (right):

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/DEPS:19: "manage_password_item_view_controller.mm": [
this seems a bit ad-hoc?

[tapted, 2015-06-05 06:38:56]

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/DEPS (right):

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/DEPS:19: "manage_password_item_view_controller.mm": [
On 2015/06/05 06:29:43, Nico wrote:
> this seems a bit ad-hoc?

yeah, it's been around for nearly a year (since r288332) and would never have
been a linker issue because it's just constants (although the dependency wasn't
present in gyp until more recently). checkdeps will fail if it's not called out.

including layout_constants seems reasonable, but It would be straightforward to
remove by copying the two constants -- views::kItemLabelSpacing and
views::kRelatedControlVerticalSpacing. Should I do this?

[Nico, 2015-06-05 06:56:13]

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/DEPS (right):

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/DEPS:19: "manage_password_item_view_controller.mm": [
On 2015/06/05 06:38:56, tapted wrote:
> On 2015/06/05 06:29:43, Nico wrote:
> > this seems a bit ad-hoc?
> 
> yeah, it's been around for nearly a year (since r288332) and would never have
> been a linker issue because it's just constants (although the dependency
wasn't
> present in gyp until more recently). checkdeps will fail if it's not called
out.
> 
> including layout_constants seems reasonable, but It would be straightforward
to
> remove by copying the two constants -- views::kItemLabelSpacing and
> views::kRelatedControlVerticalSpacing. Should I do this?

Seems nicer to me, but up to you :-)

[tapted, 2015-06-05 07:31:43]

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
File chrome/browser/ui/cocoa/DEPS (right):

https://codereview.chromium.org/1162023008/diff/60001/chrome/browser/ui/cocoa...
chrome/browser/ui/cocoa/DEPS:19: "manage_password_item_view_controller.mm": [
On 2015/06/05 06:56:13, Nico wrote:
> On 2015/06/05 06:38:56, tapted wrote:
> > On 2015/06/05 06:29:43, Nico wrote:
> > > this seems a bit ad-hoc?
> > 
> > yeah, it's been around for nearly a year (since r288332) and would never
have
> > been a linker issue because it's just constants (although the dependency
> wasn't
> > present in gyp until more recently). checkdeps will fail if it's not called
> out.
> > 
> > including layout_constants seems reasonable, but It would be straightforward
> to
> > remove by copying the two constants -- views::kItemLabelSpacing and
> > views::kRelatedControlVerticalSpacing. Should I do this?
> 
> Seems nicer to me, but up to you :-)

Done. (and yeah - I think it's nicer too.. and the more common practice - it's
unlikely we'd want these layouts influencing each other). Code change is in
http://crrev.com/1157573014 so it's not mingling with the DEPS change.

[Nico, 2015-06-05 21:47:25]

lgtm

[tapted, 2015-06-09 01:32:47]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2015-06-09 01:35:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1162023008/80001

[commit-bot: I haz the power, 2015-06-09 01:45:38]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-06-09 01:46:16]

Patchset 5 (id:??) landed as
https://crrev.com/76e0a54543e89070695a03b83c7c7ad9f7a4edbf
Cr-Commit-Position: refs/heads/master@{#333418}