2015-08-12 01:25:00 +03:00
|
|
|
#!/usr/bin/env python
|
2014-03-20 02:01:39 +04:00
|
|
|
# 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.
|
|
|
|
|
2016-02-09 07:27:52 +03:00
|
|
|
import glob
|
2014-03-20 02:01:39 +04:00
|
|
|
import json
|
|
|
|
import os
|
|
|
|
import pipes
|
2016-06-01 21:37:18 +03:00
|
|
|
import platform
|
2014-03-20 02:01:39 +04:00
|
|
|
import shutil
|
2016-06-01 21:37:18 +03:00
|
|
|
import stat
|
2014-03-20 02:01:39 +04:00
|
|
|
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'))
|
2014-04-09 05:56:20 +04:00
|
|
|
json_data_file = os.path.join(script_dir, 'win_toolchain.json')
|
2014-03-20 02:01:39 +04:00
|
|
|
|
|
|
|
|
|
|
|
import gyp
|
|
|
|
|
|
|
|
|
2016-03-11 22:55:25 +03:00
|
|
|
# Use MSVS2015 as the default toolchain.
|
|
|
|
CURRENT_DEFAULT_TOOLCHAIN_VERSION = '2015'
|
2016-01-16 01:29:57 +03:00
|
|
|
|
|
|
|
|
2014-04-09 05:56:20 +04:00
|
|
|
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.
|
2016-06-01 21:37:18 +03:00
|
|
|
|
|
|
|
Return value is [x64path, x86path] or None
|
2014-03-20 02:01:39 +04:00
|
|
|
"""
|
2015-11-21 05:21:52 +03:00
|
|
|
vs_runtime_dll_dirs = None
|
2014-03-20 02:01:39 +04:00
|
|
|
depot_tools_win_toolchain = \
|
|
|
|
bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1')))
|
2015-08-12 01:25:00 +03:00
|
|
|
# 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).
|
2015-08-26 02:03:35 +03:00
|
|
|
if ((sys.platform in ('win32', 'cygwin') or os.path.exists(json_data_file))
|
|
|
|
and depot_tools_win_toolchain):
|
2016-01-16 01:29:57 +03:00
|
|
|
if ShouldUpdateToolchain():
|
2014-08-14 18:03:30 +04:00
|
|
|
Update()
|
2014-04-09 05:56:20 +04:00
|
|
|
with open(json_data_file, 'r') as tempf:
|
2014-03-20 02:01:39 +04:00
|
|
|
toolchain_data = json.load(tempf)
|
|
|
|
|
|
|
|
toolchain = toolchain_data['path']
|
|
|
|
version = toolchain_data['version']
|
2015-06-02 04:15:44 +03:00
|
|
|
win_sdk = toolchain_data.get('win_sdk')
|
|
|
|
if not win_sdk:
|
|
|
|
win_sdk = toolchain_data['win8sdk']
|
2014-03-20 02:01:39 +04:00
|
|
|
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
|
2015-11-21 05:21:52 +03:00
|
|
|
vs_runtime_dll_dirs = toolchain_data['runtime_dirs']
|
2014-03-20 02:01:39 +04:00
|
|
|
|
|
|
|
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'))
|
2015-06-02 04:15:44 +03:00
|
|
|
gyp_defines_dict['windows_sdk_path'] = win_sdk
|
2014-03-20 02:01:39 +04:00
|
|
|
os.environ['GYP_DEFINES'] = ' '.join('%s=%s' % (k, pipes.quote(str(v)))
|
|
|
|
for k, v in gyp_defines_dict.iteritems())
|
2015-06-02 04:15:44 +03:00
|
|
|
os.environ['WINDOWSSDKDIR'] = win_sdk
|
2014-03-20 02:01:39 +04:00
|
|
|
os.environ['WDK_DIR'] = wdk
|
|
|
|
# Include the VS runtime in the PATH in case it's not machine-installed.
|
2016-02-15 21:18:01 +03:00
|
|
|
runtime_path = os.path.pathsep.join(vs_runtime_dll_dirs)
|
|
|
|
os.environ['PATH'] = runtime_path + os.path.pathsep + os.environ['PATH']
|
2016-01-07 19:30:12 +03:00
|
|
|
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()
|
2016-01-19 03:39:08 +03:00
|
|
|
if not 'GYP_MSVS_VERSION' in os.environ:
|
|
|
|
os.environ['GYP_MSVS_VERSION'] = GetVisualStudioVersion()
|
2016-01-07 19:30:12 +03:00
|
|
|
|
2016-06-01 21:37:18 +03:00
|
|
|
# When using an installed toolchain these files aren't needed in the output
|
|
|
|
# directory in order to run binaries locally, but they are needed in order
|
|
|
|
# to create isolates or the mini_installer. Copying them to the output
|
|
|
|
# directory ensures that they are available when needed.
|
|
|
|
bitness = platform.architecture()[0]
|
|
|
|
# When running 64-bit python the x64 DLLs will be in System32
|
|
|
|
x64_path = 'System32' if bitness == '64bit' else 'Sysnative'
|
|
|
|
x64_path = os.path.join(r'C:\Windows', x64_path)
|
|
|
|
vs_runtime_dll_dirs = [x64_path, r'C:\Windows\SysWOW64']
|
|
|
|
|
2015-11-21 05:21:52 +03:00
|
|
|
return vs_runtime_dll_dirs
|
2014-03-20 02:01:39 +04:00
|
|
|
|
|
|
|
|
2016-01-07 19:30:12 +03:00
|
|
|
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.')
|
|
|
|
|
|
|
|
|
2016-01-13 05:23:30 +03:00
|
|
|
def GetVisualStudioVersion():
|
2016-01-16 01:29:57 +03:00
|
|
|
"""Return GYP_MSVS_VERSION of Visual Studio.
|
2016-01-13 05:23:30 +03:00
|
|
|
"""
|
2016-01-16 01:29:57 +03:00
|
|
|
return os.environ.get('GYP_MSVS_VERSION', CURRENT_DEFAULT_TOOLCHAIN_VERSION)
|
2016-01-13 05:23:30 +03:00
|
|
|
|
|
|
|
|
2016-01-07 19:30:12 +03:00
|
|
|
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.
|
2016-01-13 05:23:30 +03:00
|
|
|
version_as_year = GetVisualStudioVersion()
|
2016-01-07 19:30:12 +03:00
|
|
|
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))
|
|
|
|
|
|
|
|
|
2015-06-02 04:15:44 +03:00
|
|
|
def _VersionNumber():
|
|
|
|
"""Gets the standard version number ('120', '140', etc.) based on
|
|
|
|
GYP_MSVS_VERSION."""
|
2016-01-13 05:23:30 +03:00
|
|
|
vs_version = GetVisualStudioVersion()
|
|
|
|
if vs_version == '2013':
|
2015-06-02 04:15:44 +03:00
|
|
|
return '120'
|
2016-01-13 05:23:30 +03:00
|
|
|
elif vs_version == '2015':
|
2015-06-02 04:15:44 +03:00
|
|
|
return '140'
|
|
|
|
else:
|
|
|
|
raise ValueError('Unexpected GYP_MSVS_VERSION')
|
|
|
|
|
|
|
|
|
2016-02-09 07:27:52 +03:00
|
|
|
def _CopyRuntimeImpl(target, source, verbose=True):
|
2016-04-18 18:29:14 +03:00
|
|
|
"""Copy |source| to |target| if it doesn't already exist or if it needs to be
|
|
|
|
updated (comparing last modified time as an approximate float match as for
|
|
|
|
some reason the values tend to differ by ~1e-07 despite being copies of the
|
|
|
|
same file... https://crbug.com/603603).
|
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.isdir(os.path.dirname(target)) and
|
|
|
|
(not os.path.isfile(target) or
|
2016-04-18 18:29:14 +03:00
|
|
|
abs(os.stat(target).st_mtime - os.stat(source).st_mtime) >= 0.01)):
|
2016-02-09 07:27:52 +03:00
|
|
|
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):
|
2016-06-01 21:37:18 +03:00
|
|
|
# Make the file writable so that we can delete it now.
|
|
|
|
os.chmod(target, stat.S_IWRITE)
|
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
|
|
|
os.unlink(target)
|
|
|
|
shutil.copy2(source, target)
|
2016-06-01 21:37:18 +03:00
|
|
|
# Make the file writable so that we can overwrite or delete it later.
|
|
|
|
os.chmod(target, stat.S_IWRITE)
|
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
|
|
|
|
|
|
|
|
2015-06-02 04:15:44 +03:00
|
|
|
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)
|
|
|
|
|
|
|
|
|
2016-02-23 02:09:18 +03:00
|
|
|
def _CopyRuntime2015(target_dir, source_dir, dll_pattern, suffix):
|
2015-06-02 04:15:44 +03:00
|
|
|
"""Copy both the msvcp and vccorlib runtime DLLs, only if the target doesn't
|
|
|
|
exist, but the target directory does exist."""
|
2015-12-17 23:44:35 +03:00
|
|
|
for file_part in ('msvcp', 'vccorlib', 'vcruntime'):
|
2015-06-02 04:15:44 +03:00
|
|
|
dll = dll_pattern % file_part
|
|
|
|
target = os.path.join(target_dir, dll)
|
|
|
|
source = os.path.join(source_dir, dll)
|
|
|
|
_CopyRuntimeImpl(target, source)
|
2016-06-01 21:37:18 +03:00
|
|
|
# OS installs of Visual Studio (and all installs of Windows 10) put the
|
|
|
|
# universal CRT files in c:\Windows\System32\downlevel - look for them there
|
|
|
|
# to support DEPOT_TOOLS_WIN_TOOLCHAIN=0.
|
|
|
|
if os.path.exists(os.path.join(source_dir, 'downlevel')):
|
|
|
|
ucrt_src_glob = os.path.join(source_dir, 'downlevel', 'api-ms-win-*.dll')
|
|
|
|
else:
|
|
|
|
ucrt_src_glob = os.path.join(source_dir, 'api-ms-win-*.dll')
|
|
|
|
ucrt_files = glob.glob(ucrt_src_glob)
|
|
|
|
assert len(ucrt_files) > 0
|
|
|
|
for ucrt_src_file in ucrt_files:
|
2016-02-23 02:09:18 +03:00
|
|
|
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))
|
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
|
|
|
|
|
|
|
|
2015-11-21 05:21:52 +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"
|
2016-01-13 05:23:30 +03:00
|
|
|
if GetVisualStudioVersion() == '2015':
|
2016-02-23 02:09:18 +03:00
|
|
|
_CopyRuntime2015(target_dir, source_dir, '%s140' + suffix, suffix)
|
2015-11-21 05:21:52 +03:00
|
|
|
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)
|
|
|
|
|
|
|
|
|
2014-03-20 02:01:39 +04:00
|
|
|
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.
|
2015-11-21 05:21:52 +03:00
|
|
|
|
|
|
|
This is used for the GYP build and gclient runhooks.
|
2014-03-20 02:01:39 +04:00
|
|
|
"""
|
|
|
|
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)
|
2015-11-21 05:21:52 +03:00
|
|
|
_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
|
|
|
|
|
|
|
|
2015-02-20 05:55:19 +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'.
|
2015-02-20 05:55:19 +03:00
|
|
|
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.
|
2015-11-21 05:21:52 +03:00
|
|
|
|
|
|
|
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
|
|
|
"""
|
2015-11-21 05:21:52 +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
|
|
|
|
|
2015-11-21 05:21:52 +03:00
|
|
|
x64_runtime, x86_runtime = vs_runtime_dll_dirs
|
2015-02-20 05:55:19 +03:00
|
|
|
runtime_dir = x64_runtime if target_cpu == 'x64' else x86_runtime
|
2015-11-21 05:21:52 +03:00
|
|
|
_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':
|
2015-11-21 05:21:52 +03:00
|
|
|
_CopyRuntime(target_dir, runtime_dir, target_cpu, debug=True)
|
2014-07-22 04:18:32 +04:00
|
|
|
|
2014-03-20 02:01:39 +04:00
|
|
|
|
2014-04-09 05:56:20 +04:00
|
|
|
def _GetDesiredVsToolchainHashes():
|
|
|
|
"""Load a list of SHA1s corresponding to the toolchains that we want installed
|
|
|
|
to build with."""
|
2016-01-13 05:23:30 +03:00
|
|
|
if GetVisualStudioVersion() == '2015':
|
Switch to VS 2015 Update 3
VS 2015 Update 3 offers numerous improvements such as improved
language conformance, fixes to avoid linker crashes, and
improved code-gen for faster performance. Update 3 also resolves
some problems with incremental linking silently falling back to
a full link.
It also fixes an internal compiler error in /analyze builds.
The landmines change is needed because otherwise things like the
out\Release\cdb directory do not get regenerated.
The process for creating this package is:
- Create a clean Windows VM running Windows Server 2012 R2 (en_windows_server_2012_r2_vl_with_update_x64_dvd_6052766.iso, SHA1: 247EAEE5628850A41F0C51471656AAFB2492EA08, Standard Edition)
- Install depot tools, run ‘gclient’, and add depot_tools to the path
- Install VS 2015 Professional Update 3 - must have been installed after July 12th to get the latest fixes - with these settings and nothing else:
* Visual C++ and make sure the three nodes underneath are also selected
* Under Universal Windows App Development Tools make sure the "Tools (1.4.1) and Windows 10 SDK (10.0.14393)" and the "Windows 10 SDK (10.0.10586)" nodes are selected and nothing else
- Copy the *Debugger and Tools*.msi installers from another machine and run them. The 10.0.14393 versions (Anniversary Edition) should be used.
- Then run:
python depot_tools\win_toolchain\package_from_installed.py 2015
It is also possible to package the 14393 SDK by running this command,
but that change is being saved for later:
python depot_tools\win_toolchain\package_from_installed.py 2015 -w 10.0.14393.0
BUG=627216,636468,427616,637456
Review-Url: https://codereview.chromium.org/2106203002
Cr-Original-Commit-Position: refs/heads/master@{#417157}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 02343c661ee0482cb73ad0cf861999f2c57eeb11
2016-09-08 04:53:00 +03:00
|
|
|
# Update 3 final with patches with 10.0.10586.0 SDK.
|
|
|
|
return ['d5dc33b15d1b2c086f2f6632e2fd15882f80dbd3']
|
2015-06-02 04:15:44 +03:00
|
|
|
else:
|
2016-04-13 21:18:53 +03:00
|
|
|
return ['03a4e939cd325d6bc5216af41b92d02dda1366a6']
|
2014-04-09 05:56:20 +04:00
|
|
|
|
|
|
|
|
2016-01-16 01:29:57 +03:00
|
|
|
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
|
|
|
|
|
|
|
|
|
2015-08-12 01:25:00 +03:00
|
|
|
def Update(force=False):
|
2014-04-09 05:56:20 +04:00
|
|
|
"""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()|.
|
|
|
|
"""
|
2015-08-12 01:25:00 +03:00
|
|
|
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
|
|
|
|
|
2014-04-09 05:56:20 +04:00
|
|
|
depot_tools_win_toolchain = \
|
|
|
|
bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1')))
|
2015-08-12 01:25:00 +03:00
|
|
|
if ((sys.platform in ('win32', 'cygwin') or force) and
|
|
|
|
depot_tools_win_toolchain):
|
2014-04-09 05:56:20 +04:00
|
|
|
import find_depot_tools
|
|
|
|
depot_tools_path = find_depot_tools.add_depot_tools_to_path()
|
2016-03-11 22:55:25 +03:00
|
|
|
# Necessary so that get_toolchain_if_necessary.py will put the VS toolkit
|
|
|
|
# in the correct directory.
|
|
|
|
os.environ['GYP_MSVS_VERSION'] = GetVisualStudioVersion()
|
2014-04-09 05:56:20 +04:00
|
|
|
get_toolchain_args = [
|
|
|
|
sys.executable,
|
|
|
|
os.path.join(depot_tools_path,
|
|
|
|
'win_toolchain',
|
|
|
|
'get_toolchain_if_necessary.py'),
|
|
|
|
'--output-json', json_data_file,
|
|
|
|
] + _GetDesiredVsToolchainHashes()
|
2015-08-12 01:25:00 +03:00
|
|
|
if force:
|
|
|
|
get_toolchain_args.append('--force')
|
2014-04-09 05:56:20 +04:00
|
|
|
subprocess.check_call(get_toolchain_args)
|
|
|
|
|
|
|
|
return 0
|
|
|
|
|
|
|
|
|
2016-03-23 03:58:06 +03:00
|
|
|
def NormalizePath(path):
|
|
|
|
while path.endswith("\\"):
|
|
|
|
path = path[:-1]
|
|
|
|
return path
|
|
|
|
|
|
|
|
|
2014-04-09 05:56:20 +04:00
|
|
|
def GetToolchainDir():
|
|
|
|
"""Gets location information about the current toolchain (must have been
|
2014-05-29 00:32:01 +04:00
|
|
|
previously updated by 'update'). This is used for the GN build."""
|
2014-11-19 22:33:28 +03:00
|
|
|
runtime_dll_dirs = SetEnvironmentAndGetRuntimeDllDirs()
|
2014-09-30 23:31:43 +04:00
|
|
|
|
|
|
|
# If WINDOWSSDKDIR is not set, search the default SDK path and set it.
|
|
|
|
if not 'WINDOWSSDKDIR' in os.environ:
|
2016-01-22 02:35:35 +03:00
|
|
|
default_sdk_path = 'C:\\Program Files (x86)\\Windows Kits\\10'
|
2014-09-30 23:31:43 +04:00
|
|
|
if os.path.isdir(default_sdk_path):
|
|
|
|
os.environ['WINDOWSSDKDIR'] = default_sdk_path
|
|
|
|
|
2014-05-29 00:32:01 +04:00
|
|
|
print '''vs_path = "%s"
|
|
|
|
sdk_path = "%s"
|
|
|
|
vs_version = "%s"
|
|
|
|
wdk_dir = "%s"
|
2014-11-19 22:33:28 +03:00
|
|
|
runtime_dirs = "%s"
|
2014-05-29 00:32:01 +04:00
|
|
|
''' % (
|
2016-03-23 03:58:06 +03:00
|
|
|
NormalizePath(os.environ['GYP_MSVS_OVERRIDE_PATH']),
|
|
|
|
NormalizePath(os.environ['WINDOWSSDKDIR']),
|
2016-01-13 05:23:30 +03:00
|
|
|
GetVisualStudioVersion(),
|
2016-03-23 03:58:06 +03:00
|
|
|
NormalizePath(os.environ.get('WDK_DIR', '')),
|
2016-02-15 21:18:01 +03:00
|
|
|
os.path.pathsep.join(runtime_dll_dirs or ['None']))
|
2014-04-09 05:56:20 +04:00
|
|
|
|
|
|
|
|
2014-03-20 02:01:39 +04:00
|
|
|
def main():
|
2014-04-09 05:56:20 +04:00
|
|
|
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,
|
2014-04-09 05:56:20 +04:00
|
|
|
}
|
|
|
|
if len(sys.argv) < 2 or sys.argv[1] not in commands:
|
|
|
|
print >>sys.stderr, 'Expected one of: %s' % ', '.join(commands)
|
2014-03-20 21:42:25 +04:00
|
|
|
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:])
|
2014-03-20 02:01:39 +04:00
|
|
|
|
2014-03-20 21:42:25 +04:00
|
|
|
|
2014-03-20 02:01:39 +04:00
|
|
|
if __name__ == '__main__':
|
|
|
|
sys.exit(main())
|