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.
|
|
|
|
|
2019-03-19 18:04:20 +03:00
|
|
|
from __future__ import print_function
|
|
|
|
|
2019-05-15 08:03:55 +03:00
|
|
|
import collections
|
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
|
2017-05-12 18:29:26 +03:00
|
|
|
import re
|
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
|
2018-11-05 11:57:34 +03:00
|
|
|
|
2018-04-17 18:26:29 +03:00
|
|
|
from gn_helpers import ToGNString
|
2014-03-20 02:01:39 +04:00
|
|
|
|
|
|
|
|
|
|
|
script_dir = os.path.dirname(os.path.realpath(__file__))
|
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
|
|
|
|
2019-05-15 08:03:55 +03:00
|
|
|
# VS versions are listed in descending order of priority (highest first).
|
|
|
|
MSVS_VERSIONS = collections.OrderedDict([
|
|
|
|
('2019', '16.0'),
|
2019-10-10 14:42:21 +03:00
|
|
|
('2017', '15.0'),
|
2019-05-15 08:03:55 +03:00
|
|
|
])
|
2016-01-16 01:29:57 +03:00
|
|
|
|
2019-10-14 22:09:41 +03:00
|
|
|
# List of preferred VC toolset version based on MSVS
|
|
|
|
MSVC_TOOLSET_VERSION = {
|
|
|
|
'2019' : 'VC142',
|
|
|
|
'2017' : 'VC141',
|
|
|
|
}
|
2016-01-16 01:29:57 +03:00
|
|
|
|
2019-11-26 01:01:53 +03:00
|
|
|
def _HostIsWindows():
|
|
|
|
"""Returns True if running on a Windows host (including under cygwin)."""
|
|
|
|
return sys.platform in ('win32', 'cygwin')
|
|
|
|
|
2014-04-09 05:56:20 +04:00
|
|
|
def SetEnvironmentAndGetRuntimeDllDirs():
|
|
|
|
"""Sets up os.environ to use the depot_tools VS toolchain with gyp, and
|
2018-11-21 17:04:12 +03:00
|
|
|
returns the location of the VC runtime DLLs so they can be copied into
|
2014-04-09 05:56:20 +04:00
|
|
|
the output directory after gyp generation.
|
2016-06-01 21:37:18 +03:00
|
|
|
|
2018-11-21 17:04:12 +03:00
|
|
|
Return value is [x64path, x86path, 'Arm64Unused'] or None. arm64path is
|
|
|
|
generated separately because there are multiple folders for the arm64 VC
|
|
|
|
runtime.
|
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).
|
2019-11-26 01:01:53 +03:00
|
|
|
if ((_HostIsWindows() or os.path.exists(json_data_file))
|
2015-08-26 02:03:35 +03:00
|
|
|
and depot_tools_win_toolchain):
|
2016-01-16 01:29:57 +03:00
|
|
|
if ShouldUpdateToolchain():
|
2019-01-30 21:48:35 +03:00
|
|
|
if len(sys.argv) > 1 and sys.argv[1] == 'update':
|
|
|
|
update_result = Update()
|
|
|
|
else:
|
|
|
|
update_result = Update(no_download=True)
|
2017-10-13 00:44:37 +03:00
|
|
|
if update_result != 0:
|
|
|
|
raise Exception('Failed to update, error code %d.' % update_result)
|
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
|
2018-11-17 00:20:04 +03:00
|
|
|
# split into separate keys for x64/x86/arm64. (See CopyDlls call below).
|
2017-05-12 18:29:26 +03:00
|
|
|
# http://crbug.com/345992
|
2015-11-21 05:21:52 +03:00
|
|
|
vs_runtime_dll_dirs = toolchain_data['runtime_dirs']
|
2018-11-17 00:20:04 +03:00
|
|
|
# The number of runtime_dirs in the toolchain_data was two (x64/x86) but
|
|
|
|
# changed to three (x64/x86/arm64) and this code needs to handle both
|
|
|
|
# possibilities, which can change independently from this code.
|
|
|
|
if len(vs_runtime_dll_dirs) == 2:
|
|
|
|
vs_runtime_dll_dirs.append('Arm64Unused')
|
2014-03-20 02:01:39 +04:00
|
|
|
|
|
|
|
os.environ['GYP_MSVS_OVERRIDE_PATH'] = toolchain
|
2017-03-11 04:46:42 +03:00
|
|
|
|
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-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
|
2018-11-17 00:20:04 +03:00
|
|
|
# ARM64 binaries will not be available in the system directories because we
|
|
|
|
# don't build on ARM64 machines.
|
2016-06-01 21:37:18 +03:00
|
|
|
x64_path = 'System32' if bitness == '64bit' else 'Sysnative'
|
2018-03-26 13:07:40 +03:00
|
|
|
x64_path = os.path.join(os.path.expandvars('%windir%'), x64_path)
|
2018-11-21 17:04:12 +03:00
|
|
|
vs_runtime_dll_dirs = [x64_path,
|
|
|
|
os.path.join(os.path.expandvars('%windir%'),
|
|
|
|
'SysWOW64'),
|
2018-11-17 00:20:04 +03:00
|
|
|
'Arm64Unused']
|
2016-06-01 21:37:18 +03:00
|
|
|
|
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():
|
2019-05-15 08:03:55 +03:00
|
|
|
"""Return best available version of Visual Studio.
|
2016-01-13 05:23:30 +03:00
|
|
|
"""
|
2020-01-22 04:19:03 +03:00
|
|
|
supported_versions = list(MSVS_VERSIONS.keys())
|
2019-05-15 08:03:55 +03:00
|
|
|
|
|
|
|
# VS installed in depot_tools for Googlers
|
|
|
|
if bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1'))):
|
2019-06-29 05:12:27 +03:00
|
|
|
return supported_versions[0]
|
2019-05-15 08:03:55 +03:00
|
|
|
|
|
|
|
# VS installed in system for external developers
|
|
|
|
supported_versions_str = ', '.join('{} ({})'.format(v,k)
|
|
|
|
for k,v in MSVS_VERSIONS.items())
|
|
|
|
available_versions = []
|
|
|
|
for version in supported_versions:
|
2020-04-10 21:02:12 +03:00
|
|
|
# Checking vs%s_install environment variables.
|
|
|
|
# For example, vs2019_install could have the value
|
|
|
|
# "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community".
|
|
|
|
# Only vs2017_install and vs2019_install are supported.
|
|
|
|
path = os.environ.get('vs%s_install' % version)
|
|
|
|
if path and os.path.exists(path):
|
|
|
|
available_versions.append(version)
|
|
|
|
break
|
|
|
|
# Detecting VS under possible paths.
|
|
|
|
path = os.path.expandvars('%ProgramFiles(x86)%' +
|
|
|
|
'/Microsoft Visual Studio/%s' % version)
|
|
|
|
if path and any(
|
|
|
|
os.path.exists(os.path.join(path, edition))
|
|
|
|
for edition in ('Enterprise', 'Professional', 'Community', 'Preview')):
|
|
|
|
available_versions.append(version)
|
|
|
|
break
|
2019-05-15 08:03:55 +03:00
|
|
|
|
|
|
|
if not available_versions:
|
|
|
|
raise Exception('No supported Visual Studio can be found.'
|
|
|
|
' Supported versions are: %s.' % supported_versions_str)
|
|
|
|
return available_versions[0]
|
2016-01-13 05:23:30 +03:00
|
|
|
|
|
|
|
|
2016-01-07 19:30:12 +03:00
|
|
|
def DetectVisualStudioPath():
|
2020-01-09 22:38:52 +03:00
|
|
|
"""Return path to the installed Visual Studio.
|
2016-01-07 19:30:12 +03:00
|
|
|
"""
|
|
|
|
|
|
|
|
# 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()
|
2018-12-29 03:57:12 +03:00
|
|
|
|
|
|
|
# The VC++ >=2017 install location needs to be located using COM instead of
|
|
|
|
# the registry. For details see:
|
|
|
|
# https://blogs.msdn.microsoft.com/heaths/2016/09/15/changes-to-visual-studio-15-setup/
|
|
|
|
# For now we use a hardcoded default with an environment variable override.
|
|
|
|
for path in (
|
|
|
|
os.environ.get('vs%s_install' % version_as_year),
|
|
|
|
os.path.expandvars('%ProgramFiles(x86)%' +
|
|
|
|
'/Microsoft Visual Studio/%s/Enterprise' %
|
|
|
|
version_as_year),
|
|
|
|
os.path.expandvars('%ProgramFiles(x86)%' +
|
|
|
|
'/Microsoft Visual Studio/%s/Professional' %
|
|
|
|
version_as_year),
|
|
|
|
os.path.expandvars('%ProgramFiles(x86)%' +
|
|
|
|
'/Microsoft Visual Studio/%s/Community' %
|
|
|
|
version_as_year),
|
|
|
|
os.path.expandvars('%ProgramFiles(x86)%' +
|
|
|
|
'/Microsoft Visual Studio/%s/Preview' %
|
|
|
|
version_as_year)):
|
|
|
|
if path and os.path.exists(path):
|
|
|
|
return path
|
2016-01-07 19:30:12 +03:00
|
|
|
|
2020-01-09 22:38:52 +03:00
|
|
|
raise Exception('Visual Studio Version %s not found.' % version_as_year)
|
2016-01-07 19:30:12 +03:00
|
|
|
|
|
|
|
|
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:
|
2019-03-19 18:04:20 +03:00
|
|
|
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):
|
2017-09-06 02:30:13 +03:00
|
|
|
# Make the file writable so that we can delete it now, and keep it
|
|
|
|
# readable.
|
|
|
|
os.chmod(target, stat.S_IWRITE | stat.S_IREAD)
|
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)
|
2017-09-06 02:30:13 +03:00
|
|
|
# Make the file writable so that we can overwrite or delete it later,
|
|
|
|
# keep it readable.
|
|
|
|
os.chmod(target, stat.S_IWRITE | stat.S_IREAD)
|
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
|
|
|
|
2019-05-22 15:34:43 +03:00
|
|
|
def _SortByHighestVersionNumberFirst(list_of_str_versions):
|
|
|
|
"""This sorts |list_of_str_versions| according to version number rules
|
|
|
|
so that version "1.12" is higher than version "1.9". Does not work
|
|
|
|
with non-numeric versions like 1.4.a8 which will be higher than
|
|
|
|
1.4.a12. It does handle the versions being embedded in file paths.
|
|
|
|
"""
|
|
|
|
def to_int_if_int(x):
|
|
|
|
try:
|
|
|
|
return int(x)
|
|
|
|
except ValueError:
|
|
|
|
return x
|
|
|
|
|
|
|
|
def to_number_sequence(x):
|
|
|
|
part_sequence = re.split(r'[\\/\.]', x)
|
|
|
|
return [to_int_if_int(x) for x in part_sequence]
|
|
|
|
|
|
|
|
list_of_str_versions.sort(key=to_number_sequence, reverse=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
|
|
|
|
2017-03-14 00:12:31 +03:00
|
|
|
def _CopyUCRTRuntime(target_dir, source_dir, target_cpu, 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."""
|
2018-11-21 17:04:12 +03:00
|
|
|
if target_cpu == 'arm64':
|
|
|
|
# Windows ARM64 VCRuntime is located at {toolchain_root}/VC/Redist/MSVC/
|
2019-10-14 22:09:41 +03:00
|
|
|
# {x.y.z}/[debug_nonredist/]arm64/Microsoft.VC14x.CRT/.
|
|
|
|
# Select VC toolset directory based on Visual Studio version
|
2018-11-21 17:04:12 +03:00
|
|
|
vc_redist_root = FindVCRedistRoot()
|
|
|
|
if suffix.startswith('.'):
|
2019-10-14 22:09:41 +03:00
|
|
|
vc_toolset_dir = 'Microsoft.{}.CRT' \
|
|
|
|
.format(MSVC_TOOLSET_VERSION[GetVisualStudioVersion()])
|
2018-11-21 17:04:12 +03:00
|
|
|
source_dir = os.path.join(vc_redist_root,
|
2019-10-14 22:09:41 +03:00
|
|
|
'arm64', vc_toolset_dir)
|
2018-11-21 17:04:12 +03:00
|
|
|
else:
|
2019-10-14 22:09:41 +03:00
|
|
|
vc_toolset_dir = 'Microsoft.{}.DebugCRT' \
|
|
|
|
.format(MSVC_TOOLSET_VERSION[GetVisualStudioVersion()])
|
2018-11-21 17:04:12 +03:00
|
|
|
source_dir = os.path.join(vc_redist_root, 'debug_nonredist',
|
2019-10-14 22:09:41 +03:00
|
|
|
'arm64', vc_toolset_dir)
|
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)
|
2017-12-06 00:09:47 +03:00
|
|
|
# Copy the UCRT files from the Windows SDK. This location includes the
|
|
|
|
# api-ms-win-crt-*.dll files that are not found in the Windows directory.
|
|
|
|
# These files are needed for component builds. If WINDOWSSDKDIR is not set
|
|
|
|
# use the default SDK path. This will be the case when
|
|
|
|
# DEPOT_TOOLS_WIN_TOOLCHAIN=0 and vcvarsall.bat has not been run.
|
2017-03-14 00:12:31 +03:00
|
|
|
win_sdk_dir = os.path.normpath(
|
|
|
|
os.environ.get('WINDOWSSDKDIR',
|
2018-05-25 17:41:24 +03:00
|
|
|
os.path.expandvars('%ProgramFiles(x86)%'
|
|
|
|
'\\Windows Kits\\10')))
|
2018-11-17 00:20:04 +03:00
|
|
|
# ARM64 doesn't have a redist for the ucrt DLLs because they are always
|
|
|
|
# present in the OS.
|
|
|
|
if target_cpu != 'arm64':
|
2018-12-11 04:36:32 +03:00
|
|
|
# Starting with the 10.0.17763 SDK the ucrt files are in a version-named
|
|
|
|
# directory - this handles both cases.
|
|
|
|
redist_dir = os.path.join(win_sdk_dir, 'Redist')
|
2018-12-18 00:12:49 +03:00
|
|
|
version_dirs = glob.glob(os.path.join(redist_dir, '10.*'))
|
2018-12-11 04:36:32 +03:00
|
|
|
if len(version_dirs) > 0:
|
2019-05-22 15:34:43 +03:00
|
|
|
_SortByHighestVersionNumberFirst(version_dirs)
|
2018-12-11 04:36:32 +03:00
|
|
|
redist_dir = version_dirs[0]
|
|
|
|
ucrt_dll_dirs = os.path.join(redist_dir, 'ucrt', 'DLLs', target_cpu)
|
2018-11-17 00:20:04 +03:00
|
|
|
ucrt_files = glob.glob(os.path.join(ucrt_dll_dirs, 'api-ms-win-*.dll'))
|
|
|
|
assert len(ucrt_files) > 0
|
|
|
|
for ucrt_src_file in ucrt_files:
|
|
|
|
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)
|
|
|
|
# We must copy ucrtbase.dll for x64/x86, and ucrtbased.dll for all CPU types.
|
|
|
|
if target_cpu != 'arm64' or not suffix.startswith('.'):
|
2018-11-21 17:04:12 +03:00
|
|
|
if not suffix.startswith('.'):
|
|
|
|
# ucrtbased.dll is located at {win_sdk_dir}/bin/{a.b.c.d}/{target_cpu}/
|
|
|
|
# ucrt/.
|
|
|
|
sdk_redist_root = os.path.join(win_sdk_dir, 'bin')
|
|
|
|
sdk_bin_sub_dirs = os.listdir(sdk_redist_root)
|
|
|
|
# Select the most recent SDK if there are multiple versions installed.
|
2019-05-22 15:34:43 +03:00
|
|
|
_SortByHighestVersionNumberFirst(sdk_bin_sub_dirs)
|
2018-11-21 17:04:12 +03:00
|
|
|
for directory in sdk_bin_sub_dirs:
|
|
|
|
sdk_redist_root_version = os.path.join(sdk_redist_root, directory)
|
|
|
|
if not os.path.isdir(sdk_redist_root_version):
|
|
|
|
continue
|
2019-04-28 18:42:21 +03:00
|
|
|
if re.match(r'10\.\d+\.\d+\.\d+', directory):
|
2018-11-21 17:04:12 +03:00
|
|
|
source_dir = os.path.join(sdk_redist_root_version, target_cpu, 'ucrt')
|
|
|
|
break
|
2018-11-17 00:20:04 +03:00
|
|
|
_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
|
|
|
|
|
|
|
|
2018-12-05 00:42:44 +03:00
|
|
|
def FindVCComponentRoot(component):
|
|
|
|
"""Find the most recent Tools or Redist or other directory in an MSVC install.
|
|
|
|
Typical results are {toolchain_root}/VC/{component}/MSVC/{x.y.z}. The {x.y.z}
|
|
|
|
version number part changes frequently so the highest version number found is
|
|
|
|
used.
|
2017-05-20 18:00:06 +03:00
|
|
|
"""
|
2019-05-15 08:03:55 +03:00
|
|
|
|
2017-05-23 05:08:31 +03:00
|
|
|
SetEnvironmentAndGetRuntimeDllDirs()
|
2017-05-20 18:00:06 +03:00
|
|
|
assert ('GYP_MSVS_OVERRIDE_PATH' in os.environ)
|
2018-12-05 00:42:44 +03:00
|
|
|
vc_component_msvc_root = os.path.join(os.environ['GYP_MSVS_OVERRIDE_PATH'],
|
|
|
|
'VC', component, 'MSVC')
|
|
|
|
vc_component_msvc_contents = os.listdir(vc_component_msvc_root)
|
|
|
|
# Select the most recent toolchain if there are several.
|
2019-05-22 15:34:43 +03:00
|
|
|
_SortByHighestVersionNumberFirst(vc_component_msvc_contents)
|
2018-12-05 00:42:44 +03:00
|
|
|
for directory in vc_component_msvc_contents:
|
|
|
|
if not os.path.isdir(os.path.join(vc_component_msvc_root, directory)):
|
2017-05-20 18:00:06 +03:00
|
|
|
continue
|
2019-04-28 18:42:21 +03:00
|
|
|
if re.match(r'14\.\d+\.\d+', directory):
|
2018-12-05 00:42:44 +03:00
|
|
|
return os.path.join(vc_component_msvc_root, directory)
|
|
|
|
raise Exception('Unable to find the VC %s directory.' % component)
|
|
|
|
|
|
|
|
|
2018-11-21 17:04:12 +03:00
|
|
|
def FindVCRedistRoot():
|
2018-12-29 03:57:12 +03:00
|
|
|
"""In >=VS2017, Redist binaries are located in
|
2018-12-05 00:42:44 +03:00
|
|
|
{toolchain_root}/VC/Redist/MSVC/{x.y.z}/{target_cpu}/.
|
2018-11-21 17:04:12 +03:00
|
|
|
|
|
|
|
This returns the '{toolchain_root}/VC/Redist/MSVC/{x.y.z}/' path.
|
|
|
|
"""
|
2018-12-05 00:42:44 +03:00
|
|
|
return FindVCComponentRoot('Redist')
|
2018-11-21 17:04:12 +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
|
2018-12-29 03:57:12 +03:00
|
|
|
directory does exist. Handles VS 2015, 2017 and 2019."""
|
2018-11-17 00:20:04 +03:00
|
|
|
suffix = 'd.dll' if debug else '.dll'
|
2018-12-29 03:57:12 +03:00
|
|
|
# VS 2015, 2017 and 2019 use the same CRT DLLs.
|
2017-03-27 23:59:15 +03:00
|
|
|
_CopyUCRTRuntime(target_dir, source_dir, target_cpu, '%s140' + suffix,
|
|
|
|
suffix)
|
2015-11-21 05:21:52 +03:00
|
|
|
|
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'.
|
2018-11-21 17:04:12 +03:00
|
|
|
target_cpu is one of 'x86', 'x64' or 'arm64'.
|
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
|
|
|
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
|
|
|
|
|
2018-11-17 00:20:04 +03:00
|
|
|
x64_runtime, x86_runtime, arm64_runtime = vs_runtime_dll_dirs
|
|
|
|
if target_cpu == 'x64':
|
|
|
|
runtime_dir = x64_runtime
|
|
|
|
elif target_cpu == 'x86':
|
|
|
|
runtime_dir = x86_runtime
|
|
|
|
elif target_cpu == 'arm64':
|
|
|
|
runtime_dir = arm64_runtime
|
|
|
|
else:
|
|
|
|
raise Exception('Unknown target_cpu: ' + target_cpu)
|
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)
|
2017-04-20 01:27:40 +03:00
|
|
|
_CopyDebugger(target_dir, target_cpu)
|
|
|
|
|
|
|
|
|
|
|
|
def _CopyDebugger(target_dir, target_cpu):
|
2017-06-30 01:24:39 +03:00
|
|
|
"""Copy dbghelp.dll and dbgcore.dll into the requested directory as needed.
|
2017-04-20 01:27:40 +03:00
|
|
|
|
2018-11-21 17:04:12 +03:00
|
|
|
target_cpu is one of 'x86', 'x64' or 'arm64'.
|
2017-04-20 01:27:40 +03:00
|
|
|
|
|
|
|
dbghelp.dll is used when Chrome needs to symbolize stacks. Copying this file
|
|
|
|
from the SDK directory avoids using the system copy of dbghelp.dll which then
|
|
|
|
ensures compatibility with recent debug information formats, such as VS
|
|
|
|
2017 /debug:fastlink PDBs.
|
2017-06-30 01:24:39 +03:00
|
|
|
|
|
|
|
dbgcore.dll is needed when using some functions from dbghelp.dll (like
|
|
|
|
MinidumpWriteDump).
|
2017-04-20 01:27:40 +03:00
|
|
|
"""
|
|
|
|
win_sdk_dir = SetEnvironmentAndGetSDKDir()
|
|
|
|
if not win_sdk_dir:
|
|
|
|
return
|
|
|
|
|
2017-08-11 19:40:45 +03:00
|
|
|
# List of debug files that should be copied, the first element of the tuple is
|
|
|
|
# the name of the file and the second indicates if it's optional.
|
|
|
|
debug_files = [('dbghelp.dll', False), ('dbgcore.dll', True)]
|
|
|
|
for debug_file, is_optional in debug_files:
|
2017-06-30 01:24:39 +03:00
|
|
|
full_path = os.path.join(win_sdk_dir, 'Debuggers', target_cpu, debug_file)
|
|
|
|
if not os.path.exists(full_path):
|
2017-08-11 19:40:45 +03:00
|
|
|
if is_optional:
|
|
|
|
continue
|
|
|
|
else:
|
2018-05-09 17:38:58 +03:00
|
|
|
# TODO(crbug.com/773476): remove version requirement.
|
2017-08-11 19:40:45 +03:00
|
|
|
raise Exception('%s not found in "%s"\r\nYou must install the '
|
|
|
|
'"Debugging Tools for Windows" feature from the Windows'
|
2018-12-11 04:36:32 +03:00
|
|
|
' 10 SDK.'
|
2018-05-09 17:38:58 +03:00
|
|
|
% (debug_file, full_path))
|
2017-06-30 01:24:39 +03:00
|
|
|
target_path = os.path.join(target_dir, debug_file)
|
|
|
|
_CopyRuntimeImpl(target_path, full_path)
|
2017-04-20 01:27:40 +03: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
|
2019-08-14 19:48:41 +03:00
|
|
|
to build with.
|
|
|
|
|
|
|
|
When updating the toolchain, consider the following areas impacted by the
|
|
|
|
toolchain version:
|
|
|
|
|
|
|
|
* //base/win/windows_version.cc NTDDI preprocessor check
|
|
|
|
Triggers a compiler error if the available SDK is older than the minimum.
|
|
|
|
* //build/config/win/BUILD.gn NTDDI_VERSION value
|
|
|
|
Affects the availability of APIs in the toolchain headers.
|
|
|
|
* //docs/windows_build_instructions.md mentions of VS or Windows SDK.
|
|
|
|
Keeps the document consistent with the toolchain version.
|
|
|
|
"""
|
2020-01-27 21:32:13 +03:00
|
|
|
# VS 2019 Update 9 (16.3.29324.140) with 10.0.18362 SDK, 10.0.17763 version of
|
|
|
|
# Debuggers, and 10.0.17134 version of d3dcompiler_47.dll, with ARM64
|
2020-01-30 01:54:21 +03:00
|
|
|
# libraries and UWP support.
|
2019-10-22 07:28:48 +03:00
|
|
|
# See go/chromium-msvc-toolchain for instructions about how to update the
|
|
|
|
# toolchain.
|
2020-01-30 01:54:21 +03:00
|
|
|
toolchain_hash = '9ff60e43ba91947baca460d0ca3b1b980c3a2c23'
|
2019-10-10 14:42:21 +03:00
|
|
|
# Third parties that do not have access to the canonical toolchain can map
|
|
|
|
# canonical toolchain version to their own toolchain versions.
|
|
|
|
toolchain_hash_mapping_key = 'GYP_MSVS_HASH_%s' % toolchain_hash
|
|
|
|
return [os.environ.get(toolchain_hash_mapping_key, toolchain_hash)]
|
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
|
|
|
|
|
|
|
|
|
2019-01-30 21:48:35 +03:00
|
|
|
def Update(force=False, no_download=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()|.
|
2019-01-30 21:48:35 +03:00
|
|
|
If no_download is true then the toolchain will be configured if present but
|
|
|
|
will not be downloaded.
|
2014-04-09 05:56:20 +04:00
|
|
|
"""
|
2015-08-12 01:25:00 +03:00
|
|
|
if force != False and force != '--force':
|
2019-03-19 18:04:20 +03:00
|
|
|
print('Unknown parameter "%s"' % force, file=sys.stderr)
|
2015-08-12 01:25:00 +03:00
|
|
|
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')))
|
2019-11-26 01:01:53 +03:00
|
|
|
if (_HostIsWindows() 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()
|
2017-10-12 21:52:40 +03:00
|
|
|
|
|
|
|
# On Linux, the file system is usually case-sensitive while the Windows
|
|
|
|
# SDK only works on case-insensitive file systems. If it doesn't already
|
|
|
|
# exist, set up a ciopfs fuse mount to put the SDK in a case-insensitive
|
|
|
|
# part of the file system.
|
|
|
|
toolchain_dir = os.path.join(depot_tools_path, 'win_toolchain', 'vs_files')
|
2018-02-01 23:36:45 +03:00
|
|
|
# For testing this block, unmount existing mounts with
|
|
|
|
# fusermount -u third_party/depot_tools/win_toolchain/vs_files
|
2017-10-12 21:52:40 +03:00
|
|
|
if sys.platform.startswith('linux') and not os.path.ismount(toolchain_dir):
|
|
|
|
import distutils.spawn
|
|
|
|
ciopfs = distutils.spawn.find_executable('ciopfs')
|
|
|
|
if not ciopfs:
|
2018-02-01 23:36:45 +03:00
|
|
|
# ciopfs not found in PATH; try the one downloaded from the DEPS hook.
|
|
|
|
ciopfs = os.path.join(script_dir, 'ciopfs')
|
2017-10-12 21:52:40 +03:00
|
|
|
if not os.path.isdir(toolchain_dir):
|
|
|
|
os.mkdir(toolchain_dir)
|
|
|
|
if not os.path.isdir(toolchain_dir + '.ciopfs'):
|
|
|
|
os.mkdir(toolchain_dir + '.ciopfs')
|
2017-10-16 21:07:05 +03:00
|
|
|
# Without use_ino, clang's #pragma once and Wnonportable-include-path
|
|
|
|
# both don't work right, see https://llvm.org/PR34931
|
|
|
|
# use_ino doesn't slow down builds, so it seems there's no drawback to
|
|
|
|
# just using it always.
|
|
|
|
subprocess.check_call([
|
|
|
|
ciopfs, '-o', 'use_ino', toolchain_dir + '.ciopfs', toolchain_dir])
|
2017-10-12 21:52:40 +03:00
|
|
|
|
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')
|
2019-01-30 21:48:35 +03:00
|
|
|
if no_download:
|
|
|
|
get_toolchain_args.append('--no-download')
|
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):
|
2018-11-17 00:20:04 +03:00
|
|
|
while path.endswith('\\'):
|
2016-03-23 03:58:06 +03:00
|
|
|
path = path[:-1]
|
|
|
|
return path
|
|
|
|
|
|
|
|
|
2017-02-16 01:45:26 +03:00
|
|
|
def SetEnvironmentAndGetSDKDir():
|
|
|
|
"""Gets location information about the current sdk (must have been
|
2014-05-29 00:32:01 +04:00
|
|
|
previously updated by 'update'). This is used for the GN build."""
|
2017-05-02 09:12:31 +03:00
|
|
|
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:
|
2018-03-26 13:07:40 +03:00
|
|
|
default_sdk_path = os.path.expandvars('%ProgramFiles(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
|
|
|
|
|
2017-02-16 01:45:26 +03:00
|
|
|
return NormalizePath(os.environ['WINDOWSSDKDIR'])
|
|
|
|
|
|
|
|
|
|
|
|
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()
|
|
|
|
win_sdk_dir = SetEnvironmentAndGetSDKDir()
|
|
|
|
|
2019-03-19 18:04:20 +03:00
|
|
|
print('''vs_path = %s
|
2018-04-17 18:26:29 +03:00
|
|
|
sdk_path = %s
|
|
|
|
vs_version = %s
|
|
|
|
wdk_dir = %s
|
|
|
|
runtime_dirs = %s
|
2019-03-19 18:04:20 +03:00
|
|
|
''' % (ToGNString(NormalizePath(os.environ['GYP_MSVS_OVERRIDE_PATH'])),
|
|
|
|
ToGNString(win_sdk_dir), ToGNString(GetVisualStudioVersion()),
|
|
|
|
ToGNString(NormalizePath(os.environ.get('WDK_DIR', ''))),
|
|
|
|
ToGNString(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:
|
2019-03-19 18:04:20 +03:00
|
|
|
print('Expected one of: %s' % ', '.join(commands), file=sys.stderr)
|
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())
|