Always embed manifests, even in component builds!

build/common.gypi

 # Copyright (c) 2012 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.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 2036 matching lines @@
       # instead of O(N*logN). This is particularly slow under memory
       # tools like ThreadSanitizer so we want it to be disablable.
       # See http://msdn.microsoft.com/en-us/library/aa985982(v=VS.80).aspx
       'win_debug_disable_iterator_debugging%': '0',
 
       # An application manifest fragment to declare compatibility settings for
       # 'executable' targets. Ignored in other target type.
       'win_exe_compatibility_manifest%':
           '<(DEPTH)\\build\\win\\compatibility.manifest',
 
-      # Set to 1 to generate external manifest instead of embedding it for
-      # 'executable' target. Does nothing for other target type. This flag is
-      # used to make mini_installer compatible with the component build.
-      # See http://crbug.com/127233
-      'win_use_external_manifest%': 0,
-
       'release_extra_cflags%': '',
       'debug_extra_cflags%': '',
 
       'release_valgrind_build%': '<(release_valgrind_build)',
 
       # the non-qualified versions are widely assumed to be *nix-only
       'win_release_extra_cflags%': '',
       'win_debug_extra_cflags%': '',
 
       # TODO(thakis): Make this a blacklist instead, http://crbug.com/101600
@@ skipping 2646 matching lines @@
             'ProxyFileName': '$(InputName)_p.c',
           },
           'VCResourceCompilerTool': {
             'Culture' : '1033',
             'AdditionalIncludeDirectories': [
               '<(DEPTH)',
               '<(SHARED_INTERMEDIATE_DIR)',
             ],
           },
           'target_conditions': [
+            ['_type=="executable"', {
+              'VCManifestTool': {
+                'EmbedManifest': 'true',
+              },
+            }],
             ['_type=="executable" and ">(win_exe_compatibility_manifest)"!=""', {
               'VCManifestTool': {
                 'AdditionalManifestFiles': [
                   '>(win_exe_compatibility_manifest)',
                 ],
               },
             }],
-            ['_type=="executable" and >(win_use_external_manifest)==0', {
-              'VCManifestTool': {
-                'EmbedManifest': 'true',
-              }
-            }],
-            ['_type=="executable" and >(win_use_external_manifest)==1', {
-              'VCManifestTool': {
-                'EmbedManifest': 'false',
-              }
-            }],
           ],
           'conditions': [
             ['clang==1', {
               # Building with Clang on Windows is a work in progress and very
               # experimental. See crbug.com/82385.
               'VCCLCompilerTool': {
                 'WarnAsError': 'false',
                 'RuntimeTypeInfo': 'false',
                 'AdditionalOptions': [
                   '/fallback',
@@ skipping 271 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }