chromium-src-build/vs_toolchain.py

370 строки
13 KiB
Python
Исходник Обычный вид История

#!/usr/bin/env python
# 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.
import glob
import json
import os
import pipes
import shutil
import subprocess
import sys
script_dir = os.path.dirname(os.path.realpath(__file__))
chrome_src = os.path.abspath(os.path.join(script_dir, os.pardir))
SRC_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
sys.path.insert(0, os.path.join(chrome_src, 'tools', 'gyp', 'pylib'))
json_data_file = os.path.join(script_dir, 'win_toolchain.json')
import gyp
Revert of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1676263003/ ) Reason for revert: Speculative revert to see if it fixes the "Duplicate COMDAT" compile error; will reland if it doesn't. Googling indicates that we have fought with "Duplicate COMDAT" errors in the past as part of trying to bring in VS 2015. This error occurred in #374346, which is a revert of #374322 due to that CL causing test failures on Linux. Note that the Windows compiler switch landed in #374324. Here is the error in question (from https://build.chromium.org/p/chromium.win/buildstatus?builder=Win%20x64%20Builder%20%28dbg%29&number=18343): FAILED: C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-with-manifests environment.x64 True mojo_system_impl.dll "C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-wrapper environment.x64 False link.exe /nologo /IMPLIB:mojo_system_impl.dll.lib /DLL /OUT:mojo_system_impl.dll @mojo_system_impl.dll.rsp" 2 mt.exe rc.exe "obj\third_party\mojo\mojo_system_impl.mojo_system_impl.dll.intermediate.manifest" obj\third_party\mojo\mojo_system_impl.mojo_system_impl.dll.generated.manifest mojo_system_impl2.node_controller.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '??1?$Callback@$$A6AXAEBVPortRef@ports@edk@mojo@@@Z@base@@QEAA@XZ' Original issue's description: > Reland of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1680533004/ ) > > Reason for revert: > The GPU bot problem (a bug with swarming tests on component builds) is fixed with crrev.com/1676943002 > > Original issue's description: > > Revert of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1679693002/ ) > > > > Reason for revert: > > This breaks GPU win debug bots (https://build.chromium.org/p/chromium.gpu/builders/Win7%20Debug%20%28NVIDIA%29/builds/36633 for example, every GPU test is crashing) > > > > Original issue's description: > > > Reland of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1678663002/ ) > > > > > > Reason for revert: > > > Issues that forced revert of VS 2015 as default compiler are believed to be fixed. > > > > > > Original issue's description: > > > > Revert of Change default Windows compiler to VS 2015 (patchset #10 id:180001 of https://codereview.chromium.org/1598493004/ ) > > > > > > > > Reason for revert: > > > > Speculative for https://code.google.com/p/chromium/issues/detail?id=498544#c20 . Will reland if this doesn't help. > > > > > > > > Original issue's description: > > > > > Change default Windows compiler to VS 2015 > > > > > > > > > > The change to get_landmines.py is there because modifying this file > > > > > affects analyze behavior so that all tests run. Changing the printed > > > > > message is purely a side effect. > > > > > > > > > > This change also removes some redundant INCLUDE paths. These are > > > > > unnecessary when building with VS 2015 (because it defaults to the > > > > > Windows 10 SDK) and actively harmful (they make the INCLUDE path > > > > > problematically long). > > > > > > > > > > BUG=440500,584782 > > > > > > > > > > Committed: https://crrev.com/4c17ac0db59d7dbe78734950f83912ab564bd6fe > > > > > Cr-Commit-Position: refs/heads/master@{#373955} > > > > > > > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,brucedawson@chromium.org > > > > # Skipping CQ checks because original CL landed less than 1 days ago. > > > > NOPRESUBMIT=true > > > > NOTREECHECKS=true > > > > NOTRY=true > > > > BUG=440500,584782 > > > > > > > > Committed: https://crrev.com/bbc766aef1bd8cb0d9546fec9abf264e7d8c1d96 > > > > Cr-Commit-Position: refs/heads/master@{#374013} > > > > > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org > > > # Not skipping CQ checks because original CL landed more than 1 days ago. > > > BUG=440500,584782 > > > > > > Committed: https://crrev.com/20e99ecb08da22582d435c1a5bba0a5c96345da3 > > > Cr-Commit-Position: refs/heads/master@{#374058} > > > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org,brucedawson@chromium.org > > # Skipping CQ checks because original CL landed less than 1 days ago. > > NOPRESUBMIT=true > > NOTREECHECKS=true > > NOTRY=true > > BUG=440500,584782 > > > > Committed: https://crrev.com/03f6b0af0a3a0127f5e939095157079659ab7cc8 > > Cr-Commit-Position: refs/heads/master@{#374062} > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org,zmo@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG=440500,584782 > > Committed: https://crrev.com/36f03f2ac1f92b6f41129f013f8a808f7b9127fc > Cr-Commit-Position: refs/heads/master@{#374324} TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org,zmo@chromium.org,brucedawson@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=440500,584782 Review URL: https://codereview.chromium.org/1680123002 Cr-Original-Commit-Position: refs/heads/master@{#374349} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: b9643d8169d78b6f3fdbc43895c5e830655291d9
2016-02-09 14:17:24 +03:00
# Use MSVS2013 as the default toolchain.
CURRENT_DEFAULT_TOOLCHAIN_VERSION = '2013'
def SetEnvironmentAndGetRuntimeDllDirs():
"""Sets up os.environ to use the depot_tools VS toolchain with gyp, and
returns the location of the VS runtime DLLs so they can be copied into
the output directory after gyp generation.
"""
vs_runtime_dll_dirs = None
depot_tools_win_toolchain = \
bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1')))
# When running on a non-Windows host, only do this if the SDK has explicitly
# been downloaded before (in which case json_data_file will exist).
if ((sys.platform in ('win32', 'cygwin') or os.path.exists(json_data_file))
and depot_tools_win_toolchain):
if ShouldUpdateToolchain():
Update()
with open(json_data_file, 'r') as tempf:
toolchain_data = json.load(tempf)
toolchain = toolchain_data['path']
version = toolchain_data['version']
win_sdk = toolchain_data.get('win_sdk')
if not win_sdk:
win_sdk = toolchain_data['win8sdk']
wdk = toolchain_data['wdk']
# TODO(scottmg): The order unfortunately matters in these. They should be
# split into separate keys for x86 and x64. (See CopyVsRuntimeDlls call
# below). http://crbug.com/345992
vs_runtime_dll_dirs = toolchain_data['runtime_dirs']
os.environ['GYP_MSVS_OVERRIDE_PATH'] = toolchain
os.environ['GYP_MSVS_VERSION'] = version
# We need to make sure windows_sdk_path is set to the automated
# toolchain values in GYP_DEFINES, but don't want to override any
# otheroptions.express
# values there.
gyp_defines_dict = gyp.NameValueListToDict(gyp.ShlexEnv('GYP_DEFINES'))
gyp_defines_dict['windows_sdk_path'] = win_sdk
os.environ['GYP_DEFINES'] = ' '.join('%s=%s' % (k, pipes.quote(str(v)))
for k, v in gyp_defines_dict.iteritems())
os.environ['WINDOWSSDKDIR'] = win_sdk
os.environ['WDK_DIR'] = wdk
# Include the VS runtime in the PATH in case it's not machine-installed.
runtime_path = os.path.pathsep.join(vs_runtime_dll_dirs)
os.environ['PATH'] = runtime_path + os.path.pathsep + os.environ['PATH']
elif sys.platform == 'win32' and not depot_tools_win_toolchain:
if not 'GYP_MSVS_OVERRIDE_PATH' in os.environ:
os.environ['GYP_MSVS_OVERRIDE_PATH'] = DetectVisualStudioPath()
if not 'GYP_MSVS_VERSION' in os.environ:
os.environ['GYP_MSVS_VERSION'] = GetVisualStudioVersion()
return vs_runtime_dll_dirs
def _RegistryGetValueUsingWinReg(key, value):
"""Use the _winreg module to obtain the value of a registry key.
Args:
key: The registry key.
value: The particular registry value to read.
Return:
contents of the registry key's value, or None on failure. Throws
ImportError if _winreg is unavailable.
"""
import _winreg
try:
root, subkey = key.split('\\', 1)
assert root == 'HKLM' # Only need HKLM for now.
with _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, subkey) as hkey:
return _winreg.QueryValueEx(hkey, value)[0]
except WindowsError:
return None
def _RegistryGetValue(key, value):
try:
return _RegistryGetValueUsingWinReg(key, value)
except ImportError:
raise Exception('The python library _winreg not found.')
def GetVisualStudioVersion():
"""Return GYP_MSVS_VERSION of Visual Studio.
"""
return os.environ.get('GYP_MSVS_VERSION', CURRENT_DEFAULT_TOOLCHAIN_VERSION)
def DetectVisualStudioPath():
"""Return path to the GYP_MSVS_VERSION of Visual Studio.
"""
# Note that this code is used from
# build/toolchain/win/setup_toolchain.py as well.
version_as_year = GetVisualStudioVersion()
year_to_version = {
'2013': '12.0',
'2015': '14.0',
}
if version_as_year not in year_to_version:
raise Exception(('Visual Studio version %s (from GYP_MSVS_VERSION)'
' not supported. Supported versions are: %s') % (
version_as_year, ', '.join(year_to_version.keys())))
version = year_to_version[version_as_year]
keys = [r'HKLM\Software\Microsoft\VisualStudio\%s' % version,
r'HKLM\Software\Wow6432Node\Microsoft\VisualStudio\%s' % version]
for key in keys:
path = _RegistryGetValue(key, 'InstallDir')
if not path:
continue
path = os.path.normpath(os.path.join(path, '..', '..'))
return path
raise Exception(('Visual Studio Version %s (from GYP_MSVS_VERSION)'
' not found.') % (version_as_year))
def _VersionNumber():
"""Gets the standard version number ('120', '140', etc.) based on
GYP_MSVS_VERSION."""
vs_version = GetVisualStudioVersion()
if vs_version == '2013':
return '120'
elif vs_version == '2015':
return '140'
else:
raise ValueError('Unexpected GYP_MSVS_VERSION')
def _CopyRuntimeImpl(target, source, verbose=True):
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
"""Copy |source| to |target| if it doesn't already exist or if it
needs to be updated.
"""
if (os.path.isdir(os.path.dirname(target)) and
(not os.path.isfile(target) or
os.stat(target).st_mtime != os.stat(source).st_mtime)):
if verbose:
print 'Copying %s to %s...' % (source, target)
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
if os.path.exists(target):
os.unlink(target)
shutil.copy2(source, target)
def _CopyRuntime2013(target_dir, source_dir, dll_pattern):
"""Copy both the msvcr and msvcp runtime DLLs, only if the target doesn't
exist, but the target directory does exist."""
for file_part in ('p', 'r'):
dll = dll_pattern % file_part
target = os.path.join(target_dir, dll)
source = os.path.join(source_dir, dll)
_CopyRuntimeImpl(target, source)
def _CopyRuntime2015(target_dir, source_dir, dll_pattern):
"""Copy both the msvcp and vccorlib runtime DLLs, only if the target doesn't
exist, but the target directory does exist."""
for file_part in ('msvcp', 'vccorlib', 'vcruntime'):
dll = dll_pattern % file_part
target = os.path.join(target_dir, dll)
source = os.path.join(source_dir, dll)
_CopyRuntimeImpl(target, source)
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
def _CopyRuntime(target_dir, source_dir, target_cpu, debug):
"""Copy the VS runtime DLLs, only if the target doesn't exist, but the target
directory does exist. Handles VS 2013 and VS 2015."""
suffix = "d.dll" if debug else ".dll"
if GetVisualStudioVersion() == '2015':
_CopyRuntime2015(target_dir, source_dir, '%s140' + suffix)
ucrt_src_dir = os.path.join(source_dir, 'api-ms-win-*.dll')
print 'Copying %s to %s...' % (ucrt_src_dir, target_dir)
for ucrt_src_file in glob.glob(ucrt_src_dir):
file_part = os.path.basename(ucrt_src_file)
ucrt_dst_file = os.path.join(target_dir, file_part)
_CopyRuntimeImpl(ucrt_dst_file, ucrt_src_file, False)
_CopyRuntimeImpl(os.path.join(target_dir, 'ucrtbase' + suffix),
os.path.join(source_dir, 'ucrtbase' + suffix))
else:
_CopyRuntime2013(target_dir, source_dir, 'msvc%s120' + suffix)
# Copy the PGO runtime library to the release directories.
if not debug and os.environ.get('GYP_MSVS_OVERRIDE_PATH'):
pgo_x86_runtime_dir = os.path.join(os.environ.get('GYP_MSVS_OVERRIDE_PATH'),
'VC', 'bin')
pgo_x64_runtime_dir = os.path.join(pgo_x86_runtime_dir, 'amd64')
pgo_runtime_dll = 'pgort' + _VersionNumber() + '.dll'
if target_cpu == "x86":
source_x86 = os.path.join(pgo_x86_runtime_dir, pgo_runtime_dll)
if os.path.exists(source_x86):
_CopyRuntimeImpl(os.path.join(target_dir, pgo_runtime_dll), source_x86)
elif target_cpu == "x64":
source_x64 = os.path.join(pgo_x64_runtime_dir, pgo_runtime_dll)
if os.path.exists(source_x64):
_CopyRuntimeImpl(os.path.join(target_dir, pgo_runtime_dll),
source_x64)
else:
raise NotImplementedError("Unexpected target_cpu value:" + target_cpu)
def CopyVsRuntimeDlls(output_dir, runtime_dirs):
"""Copies the VS runtime DLLs from the given |runtime_dirs| to the output
directory so that even if not system-installed, built binaries are likely to
be able to run.
This needs to be run after gyp has been run so that the expected target
output directories are already created.
This is used for the GYP build and gclient runhooks.
"""
x86, x64 = runtime_dirs
out_debug = os.path.join(output_dir, 'Debug')
out_debug_nacl64 = os.path.join(output_dir, 'Debug', 'x64')
out_release = os.path.join(output_dir, 'Release')
out_release_nacl64 = os.path.join(output_dir, 'Release', 'x64')
out_debug_x64 = os.path.join(output_dir, 'Debug_x64')
out_release_x64 = os.path.join(output_dir, 'Release_x64')
if os.path.exists(out_debug) and not os.path.exists(out_debug_nacl64):
os.makedirs(out_debug_nacl64)
if os.path.exists(out_release) and not os.path.exists(out_release_nacl64):
os.makedirs(out_release_nacl64)
_CopyRuntime(out_debug, x86, "x86", debug=True)
_CopyRuntime(out_release, x86, "x86", debug=False)
_CopyRuntime(out_debug_x64, x64, "x64", debug=True)
_CopyRuntime(out_release_x64, x64, "x64", debug=False)
_CopyRuntime(out_debug_nacl64, x64, "x64", debug=True)
_CopyRuntime(out_release_nacl64, x64, "x64", debug=False)
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
def CopyDlls(target_dir, configuration, target_cpu):
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
"""Copy the VS runtime DLLs into the requested directory as needed.
configuration is one of 'Debug' or 'Release'.
target_cpu is one of 'x86' or 'x64'.
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
The debug configuration gets both the debug and release DLLs; the
release config only the latter.
This is used for the GN build.
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
"""
vs_runtime_dll_dirs = SetEnvironmentAndGetRuntimeDllDirs()
if not vs_runtime_dll_dirs:
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
return
x64_runtime, x86_runtime = vs_runtime_dll_dirs
runtime_dir = x64_runtime if target_cpu == 'x64' else x86_runtime
_CopyRuntime(target_dir, runtime_dir, target_cpu, debug=False)
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
if configuration == 'Debug':
_CopyRuntime(target_dir, runtime_dir, target_cpu, debug=True)
def _GetDesiredVsToolchainHashes():
"""Load a list of SHA1s corresponding to the toolchains that we want installed
to build with."""
if GetVisualStudioVersion() == '2015':
# Update 1 with hot fixes.
return ['b349b3cc596d5f7e13d649532ddd7e8db39db0cb']
else:
Revert of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1676263003/ ) Reason for revert: Speculative revert to see if it fixes the "Duplicate COMDAT" compile error; will reland if it doesn't. Googling indicates that we have fought with "Duplicate COMDAT" errors in the past as part of trying to bring in VS 2015. This error occurred in #374346, which is a revert of #374322 due to that CL causing test failures on Linux. Note that the Windows compiler switch landed in #374324. Here is the error in question (from https://build.chromium.org/p/chromium.win/buildstatus?builder=Win%20x64%20Builder%20%28dbg%29&number=18343): FAILED: C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-with-manifests environment.x64 True mojo_system_impl.dll "C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-wrapper environment.x64 False link.exe /nologo /IMPLIB:mojo_system_impl.dll.lib /DLL /OUT:mojo_system_impl.dll @mojo_system_impl.dll.rsp" 2 mt.exe rc.exe "obj\third_party\mojo\mojo_system_impl.mojo_system_impl.dll.intermediate.manifest" obj\third_party\mojo\mojo_system_impl.mojo_system_impl.dll.generated.manifest mojo_system_impl2.node_controller.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '??1?$Callback@$$A6AXAEBVPortRef@ports@edk@mojo@@@Z@base@@QEAA@XZ' Original issue's description: > Reland of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1680533004/ ) > > Reason for revert: > The GPU bot problem (a bug with swarming tests on component builds) is fixed with crrev.com/1676943002 > > Original issue's description: > > Revert of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1679693002/ ) > > > > Reason for revert: > > This breaks GPU win debug bots (https://build.chromium.org/p/chromium.gpu/builders/Win7%20Debug%20%28NVIDIA%29/builds/36633 for example, every GPU test is crashing) > > > > Original issue's description: > > > Reland of Change default Windows compiler to VS 2015 (patchset #1 id:1 of https://codereview.chromium.org/1678663002/ ) > > > > > > Reason for revert: > > > Issues that forced revert of VS 2015 as default compiler are believed to be fixed. > > > > > > Original issue's description: > > > > Revert of Change default Windows compiler to VS 2015 (patchset #10 id:180001 of https://codereview.chromium.org/1598493004/ ) > > > > > > > > Reason for revert: > > > > Speculative for https://code.google.com/p/chromium/issues/detail?id=498544#c20 . Will reland if this doesn't help. > > > > > > > > Original issue's description: > > > > > Change default Windows compiler to VS 2015 > > > > > > > > > > The change to get_landmines.py is there because modifying this file > > > > > affects analyze behavior so that all tests run. Changing the printed > > > > > message is purely a side effect. > > > > > > > > > > This change also removes some redundant INCLUDE paths. These are > > > > > unnecessary when building with VS 2015 (because it defaults to the > > > > > Windows 10 SDK) and actively harmful (they make the INCLUDE path > > > > > problematically long). > > > > > > > > > > BUG=440500,584782 > > > > > > > > > > Committed: https://crrev.com/4c17ac0db59d7dbe78734950f83912ab564bd6fe > > > > > Cr-Commit-Position: refs/heads/master@{#373955} > > > > > > > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,brucedawson@chromium.org > > > > # Skipping CQ checks because original CL landed less than 1 days ago. > > > > NOPRESUBMIT=true > > > > NOTREECHECKS=true > > > > NOTRY=true > > > > BUG=440500,584782 > > > > > > > > Committed: https://crrev.com/bbc766aef1bd8cb0d9546fec9abf264e7d8c1d96 > > > > Cr-Commit-Position: refs/heads/master@{#374013} > > > > > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org > > > # Not skipping CQ checks because original CL landed more than 1 days ago. > > > BUG=440500,584782 > > > > > > Committed: https://crrev.com/20e99ecb08da22582d435c1a5bba0a5c96345da3 > > > Cr-Commit-Position: refs/heads/master@{#374058} > > > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org,brucedawson@chromium.org > > # Skipping CQ checks because original CL landed less than 1 days ago. > > NOPRESUBMIT=true > > NOTREECHECKS=true > > NOTRY=true > > BUG=440500,584782 > > > > Committed: https://crrev.com/03f6b0af0a3a0127f5e939095157079659ab7cc8 > > Cr-Commit-Position: refs/heads/master@{#374062} > > TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org,zmo@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG=440500,584782 > > Committed: https://crrev.com/36f03f2ac1f92b6f41129f013f8a808f7b9127fc > Cr-Commit-Position: refs/heads/master@{#374324} TBR=dpranke@chromium.org,scottmg@chromium.org,sebmarchand@chromium.org,thakis@chromium.org,zmo@chromium.org,brucedawson@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=440500,584782 Review URL: https://codereview.chromium.org/1680123002 Cr-Original-Commit-Position: refs/heads/master@{#374349} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: b9643d8169d78b6f3fdbc43895c5e830655291d9
2016-02-09 14:17:24 +03:00
# Default to VS2013.
return ['4087e065abebdca6dbd0caca2910c6718d2ec67f']
def ShouldUpdateToolchain():
"""Check if the toolchain should be upgraded."""
if not os.path.exists(json_data_file):
return True
with open(json_data_file, 'r') as tempf:
toolchain_data = json.load(tempf)
version = toolchain_data['version']
env_version = GetVisualStudioVersion()
# If there's a mismatch between the version set in the environment and the one
# in the json file then the toolchain should be updated.
return version != env_version
def Update(force=False):
"""Requests an update of the toolchain to the specific hashes we have at
this revision. The update outputs a .json of the various configuration
information required to pass to gyp which we use in |GetToolchainDir()|.
"""
if force != False and force != '--force':
print >>sys.stderr, 'Unknown parameter "%s"' % force
return 1
if force == '--force' or os.path.exists(json_data_file):
force = True
depot_tools_win_toolchain = \
bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1')))
if ((sys.platform in ('win32', 'cygwin') or force) and
depot_tools_win_toolchain):
import find_depot_tools
depot_tools_path = find_depot_tools.add_depot_tools_to_path()
get_toolchain_args = [
sys.executable,
os.path.join(depot_tools_path,
'win_toolchain',
'get_toolchain_if_necessary.py'),
'--output-json', json_data_file,
] + _GetDesiredVsToolchainHashes()
if force:
get_toolchain_args.append('--force')
subprocess.check_call(get_toolchain_args)
return 0
def GetToolchainDir():
"""Gets location information about the current toolchain (must have been
previously updated by 'update'). This is used for the GN build."""
runtime_dll_dirs = SetEnvironmentAndGetRuntimeDllDirs()
# If WINDOWSSDKDIR is not set, search the default SDK path and set it.
if not 'WINDOWSSDKDIR' in os.environ:
default_sdk_path = 'C:\\Program Files (x86)\\Windows Kits\\10'
if os.path.isdir(default_sdk_path):
os.environ['WINDOWSSDKDIR'] = default_sdk_path
print '''vs_path = "%s"
sdk_path = "%s"
vs_version = "%s"
wdk_dir = "%s"
runtime_dirs = "%s"
''' % (
os.environ['GYP_MSVS_OVERRIDE_PATH'],
os.environ['WINDOWSSDKDIR'],
GetVisualStudioVersion(),
os.environ.get('WDK_DIR', ''),
os.path.pathsep.join(runtime_dll_dirs or ['None']))
def main():
commands = {
'update': Update,
'get_toolchain_dir': GetToolchainDir,
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
'copy_dlls': CopyDlls,
}
if len(sys.argv) < 2 or sys.argv[1] not in commands:
print >>sys.stderr, 'Expected one of: %s' % ', '.join(commands)
return 1
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
return commands[sys.argv[1]](*sys.argv[2:])
if __name__ == '__main__':
sys.exit(main())