Fix base dependency in views_examples_with_content_exe

ui/views/examples/examples.gyp

Index: ui/views/examples/examples.gyp
diff --git a/ui/views/examples/examples.gyp b/ui/views/examples/examples.gyp
index c01bac2a422b4100a45466ef3236257598747af6..50790ad639aaeb3e26eed1439a38d04173408a6d 100644
--- a/ui/views/examples/examples.gyp
+++ b/ui/views/examples/examples.gyp
@@ -161,8 +161,6 @@
       'target_name': 'views_examples_with_content_exe',
       'type': 'executable',
       'dependencies': [
-        '../../../base/base.gyp:base',
-        '../../../content/content.gyp:content',
         '../../views_content_client/views_content_client.gyp:views_content_client',
         'views_examples_with_content_lib',
       ],
@@ -171,6 +169,12 @@
         'examples_with_content_main_exe.cc',
       ],
       'conditions': [
+        ['component=="shared_library"', {
+          'dependencies': [
+            '../../../base/base.gyp:base',

[tfarina, 2016/03/31 18:46:14]

Are there other places where this is being doing like this? Sorry, but this
looks like a hack. Why should we link to base only in the shared build when the
code already depends on it no matter what?

[Will Harris, 2016/03/31 19:24:44]

I agree it's quite mysterious, it doesn't happen in GN because GN passes
individual obj files to the link stage rather than libs, and it doesn't happen
at the almost-identical configuration "views_examples_exe" and
"views_examples_lib" above.

The problem comes when two copies of the allocator end up linking into the same
executable. This happened once elsewhere in gles2_conform_support.gyp linking
via a direct and indirect dependency.

I think it has to do with link order.

[tfarina, 2016/03/31 19:53:43]

I think gn does that only if the "library" is a source_set. 
This seems to indicate that maybe the way the allocator is currently setup is
not correctly. Otherwise this would have been happening for everything else.
What is special about the allocator?

I remember seeing some changes from Primiano to make it part of base. Maybe it
has something to do with this?

Last time I looked into this (with you) I saw we build tcmalloc from base and
the gyp file is a mess and very complex. Not sure if you remember this
discussion.

+            '../../../content/content.gyp:content',
+          ],
+        }],
         ['OS=="win"', {
           'link_settings': {
             'libraries': [