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

chrome/browser/ui/cocoa/DEPS

 include_rules = [
   "+third_party/apple_sample_code",  # Apple code ImageAndTextCell.
   "+third_party/molokocacao",  # For NSBezierPath additions.
   "+third_party/ocmock",  # For unit tests.
+  # Tooklit-views dependencies shouldn't be introduced here except for special
+  # cases below.
+  "-ui/views",
 ]
+
+specific_include_rules = {
+  # Allow access to toolkit-views for specific bridging classes to integrate
+  # with a Cocoa browser window. These need to have "_views" somewhere in the
+  # file name. Mac-specific toolkit-views code that doesn't need to interact
+  # with a Cocoa browser should go under chrome/browser/ui/views.
+  ".*(_views).*\.(cc|h|mm)$": [
+    "+chrome/browser/ui/views",
+    "+ui/views",
+  ],
+  "manage_password_item_view_controller.mm": [

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

this seems a bit ad-hoc?

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

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]

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

[tapted, 2015/06/05 07:31:42]

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.

+    "+ui/views/layout/layout_constants.h",
+  ],
+}