Fix base dependency in views_examples_with_content_exe

ui/views/examples/examples.gyp

 # Copyright 2014 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 {
   'variables': {
     'chromium_code': 1,
   },
   'targets': [
     {
       # GN version: //ui/views/examples
@@ skipping 143 matching lines @@
         'views_examples_with_content_export.h',
         'webview_example.cc',
         'webview_example.h',
       ],
     },  # target_name: views_examples_with_content_lib
     {
       # GN version: //ui/views/examples/views_examples_with_content_exe
       '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',
       ],
       'sources': [
         # Note: sources list duplicated in GN build.
         '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': [
               '-limm32.lib',
               '-loleacc.lib',
             ]
           },
           'msvs_settings': {
             'VCManifestTool': {
               'AdditionalManifestFiles': [
                 'views_examples.exe.manifest',
               ],
             },
             'VCLinkerTool': {
               'SubSystem': '2',  # Set /SUBSYSTEM:WINDOWS
             },
           },
           'dependencies': [
             '../../../sandbox/sandbox.gyp:sandbox',
             '../../../content/content.gyp:sandbox_helper_win',
           ],
         }],
       ],
     },  # target_name: views_examples_with_content_exe
   ],
 }