chromium-src-build/vs_toolchain.py

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

#!/usr/bin/env python
# Copyright 2014 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
from __future__ import print_function
import collections
import glob
import json
import os
import pipes
import platform
import re
import shutil
import stat
import subprocess
import sys
from gn_helpers import ToGNString
script_dir = os.path.dirname(os.path.realpath(__file__))
json_data_file = os.path.join(script_dir, 'win_toolchain.json')
# VS versions are listed in descending order of priority (highest first).
MSVS_VERSIONS = collections.OrderedDict([
('2019', '16.0'),
Switch to VS 2019. Goma no longer supports cl.exe and the cl.exe version update in this CL hasn't been uploaded to goma's servers. Everyone who has bots that use cl.exe must make sure that these bots don't use goma before rolling this CL in. This change switches the MSVC toolchain to VS 2019 16.3.29324. Windows SDK is mostly 10.0.18362 Debuggers from 10.0.17763 d3dcompiler_47.dll from 10.0.17134 The instructions for the previous package are included below: Packaging was done on a Windows Server 2019 VM, cleanly created for this purpose. The package was created by downloading VS 2019 Update 3.29324, from https://visualstudio.microsoft.com/downloads/ and downloading the 16.3 Visual Studio Professional 2019, and then running the installer like this: $ PATH_TO_INSTALLER.EXE ^ --add Microsoft.VisualStudio.Workload.NativeDesktop ^ --add Microsoft.VisualStudio.Component.VC.ATLMFC ^ --add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^ --add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^ --includeRecommended --passive Then the 10.0.18362.0 SDK was installed from: https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk. Then Add or Remove Programs was used to modify the 10.0.18362.0 SDK to add the Debuggers package. Then the packaging script was run like this: python depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.18362.0 Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid shipping that the final packaging step was to unzip the package, copy over the two copies of that DLL from win_sdk\Redist, replace the Debuggers directory with the 10.0.17763 SDK, and then repackage the toolchain with: > python package_from_installed.py --repackage=<full-path-to-toolchain-dir> Bug: 1006238 Change-Id: I623632bd72f018a74ab513d2c79e89199915e647 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1836195 Reviewed-by: Nico Weber <thakis@chromium.org> Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Commit-Queue: Mirko Bonadei <mbonadei@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#704569} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 8e82c6ab1bc2223fa25f1a127b65071d2d58ae36
2019-10-10 14:42:21 +03:00
('2017', '15.0'),
])
# List of preferred VC toolset version based on MSVS
MSVC_TOOLSET_VERSION = {
'2019' : 'VC142',
'2017' : 'VC141',
}
def _HostIsWindows():
"""Returns True if running on a Windows host (including under cygwin)."""
return sys.platform in ('win32', 'cygwin')
def SetEnvironmentAndGetRuntimeDllDirs():
"""Sets up os.environ to use the depot_tools VS toolchain with gyp, and
returns the location of the VC runtime DLLs so they can be copied into
the output directory after gyp generation.
Return value is [x64path, x86path, 'Arm64Unused'] or None. arm64path is
generated separately because there are multiple folders for the arm64 VC
runtime.
"""
vs_runtime_dll_dirs = None
depot_tools_win_toolchain = \
bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1')))
# When running on a non-Windows host, only do this if the SDK has explicitly
# been downloaded before (in which case json_data_file will exist).
if ((_HostIsWindows() or os.path.exists(json_data_file))
and depot_tools_win_toolchain):
if ShouldUpdateToolchain():
Refuse to download new toolchain during gn gen This change relies on the depot_tools change crrev.com/c/1439805 Chromium and v8 have rolled to a new enough version of depot_tools to support this script and Angle always uses the latest version of depot_tools so there shouldn't be any script-mismatch problems caused by landing this. The toolchain used to build Chrome is supposed to be updated during "gclient runhooks" but currently if that doesn't happen (if GYP_MSVS_VERSION is changed but "gclient runhooks" isn't run) then the update will be tried during "gn gen". That works badly. It leads to attempts to parse the update output as toolchain information, it can lead to the update happening in parallel, and is generally a bad idea. This change passes --no-download to depot_tools\win_toolchain\get_toolchain_if_necessary.py when 'update' is not the command being processed so that the depot_tools script will no that it should only configure the toolchain, not try downloading it. This also prevents attempts to update the toolchain when running tools\win\setenv.bat This was tested by forcing an updated to VS 2019 and confirming that the new behavior is as desired (failing with an informative message when appropriate, working when appropriate). This includes testing that using the local toolchain (if installed) works with this change. See crrev.com/c/1426397, the CL that was used for testing on the bots. Both bugs suggest that our bots sometimes don't update the toolchain when they are supposed to. If that is the case then this change will help to flush out those bugs so that they can be fixed. Bug: 584393,662325 Change-Id: I0ef671977ea59b4f3368827c5b5ffe50ed6602f7 Reviewed-on: https://chromium-review.googlesource.com/c/1444031 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#627513} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 060aa690a1abce245184e1f251e9414a0eb8637f
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)
if update_result != 0:
raise Exception('Failed to update, error code %d.' % update_result)
with open(json_data_file, 'r') as tempf:
toolchain_data = json.load(tempf)
toolchain = toolchain_data['path']
version = toolchain_data['version']
win_sdk = toolchain_data.get('win_sdk')
if not win_sdk:
win_sdk = toolchain_data['win8sdk']
wdk = toolchain_data['wdk']
# TODO(scottmg): The order unfortunately matters in these. They should be
# split into separate keys for x64/x86/arm64. (See CopyDlls call below).
# http://crbug.com/345992
vs_runtime_dll_dirs = toolchain_data['runtime_dirs']
# 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')
os.environ['GYP_MSVS_OVERRIDE_PATH'] = toolchain
os.environ['WINDOWSSDKDIR'] = win_sdk
os.environ['WDK_DIR'] = wdk
# Include the VS runtime in the PATH in case it's not machine-installed.
runtime_path = os.path.pathsep.join(vs_runtime_dll_dirs)
os.environ['PATH'] = runtime_path + os.path.pathsep + os.environ['PATH']
elif sys.platform == 'win32' and not depot_tools_win_toolchain:
if not 'GYP_MSVS_OVERRIDE_PATH' in os.environ:
os.environ['GYP_MSVS_OVERRIDE_PATH'] = DetectVisualStudioPath()
# 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
# ARM64 binaries will not be available in the system directories because we
# don't build on ARM64 machines.
x64_path = 'System32' if bitness == '64bit' else 'Sysnative'
WinUWP store application support is out of date This is required to support building Microsoft's WinUWP store application version of WebRTC. vs_toolchain.py - needed to perform environment variable expansion for "Program Files(x86)" to correctly identify Visual Studio installation location config/BUILD.gn - remove delayimp.lib, kernel32.lib and ole32.lib from store applications (instead requires dloadhelper.lib/WindowsApp.lib must be used) BUILDCONFIG.gn - Do not use clang when compiling Windows UWP targets; - Added declare_args for is_target_winuwp rather and stripped multi defined variations of the host_os/current_os == "winrt_10", "winrt_81", "winrt_81_phone" that heavily polluted the platform / target selections (as the current targeting methodology is incorrect anyway). The host_os/current_os is always be "win" and only the target should be Windows UWP / store applications based on the target_os == "winuwp" rather than all the flavors of UWP. - Added filter for _winuwp source files (separate from just windows) - Added default configs for desktop vs store applications to correctly set the defines according to the desktop vs store targets config/win/BUILD.gn - The Windows UWP versioning assumes to be Windows 10 / store app now although a updated GN allows for targeting older Windows UWP versions/SDKs/device families. This allows the definitions for the various application support versioning and application families required for UWP to be set. - The linker calls vsvarsall.bat to be executed via toolchain/win/setup_toolchain.py in order to correctly identify the correct linker library path information for Windows store SDK targets. The hard coded and assumed library paths are fixed in all cases to be discovered from the tooling for forward future platform support in all cases. - Added ARM linkage definitions for the Windows ARM CPU required for properly targeting all three CPUs (x86, x64, arm) for universal store binaries. - Added the proper family C++/C defines required to target the various Windows store application types currently offered for Windows UWP store applications. toolchain/win/BUILD.gn - The name to support the storage of the environment variables now is passed into the setup script to allow for easier extension of the CPUs and target combinations (arm, x64, x86 in the desktop vs store variations) - "desktop" vs "store" is now specified the setup for the correct toolchain targeting - Sets true/false for is_target_winuwp is dependent on the toolchain activated (so configurations will be set correctly when the toolchain is specified for host tool targets required for build tools vs finalized application targets) - Cleaned up the Windows RT section to properly support Windows UWP toolchains toolchain/win/setup_toolchain.py - the setup was missing the arm CPU for universal binaries required for the UWP platform - The calling of vcvarsall.bat was missing the "store" option for store applications and all the CPU offered - Added returning of linker paths by searching the library environments for well-known library files expected in each of the 3 library paths required "lib", "um" and "atlmfc" R=phoglund@google.com Bug: 812814 Change-Id: If1a6b1b1bc3ed940fc8e2ce726ac016e2491e61d Reviewed-on: https://chromium-review.googlesource.com/923161 Commit-Queue: Patrik Höglund <phoglund@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#545751} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: c5686578e8f519eeec50f574b284fbc12e6e15d8
2018-03-26 13:07:40 +03:00
x64_path = os.path.join(os.path.expandvars('%windir%'), x64_path)
vs_runtime_dll_dirs = [x64_path,
os.path.join(os.path.expandvars('%windir%'),
'SysWOW64'),
'Arm64Unused']
return vs_runtime_dll_dirs
def _RegistryGetValueUsingWinReg(key, value):
"""Use the _winreg module to obtain the value of a registry key.
Args:
key: The registry key.
value: The particular registry value to read.
Return:
contents of the registry key's value, or None on failure. Throws
ImportError if _winreg is unavailable.
"""
import _winreg
try:
root, subkey = key.split('\\', 1)
assert root == 'HKLM' # Only need HKLM for now.
with _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, subkey) as hkey:
return _winreg.QueryValueEx(hkey, value)[0]
except WindowsError:
return None
def _RegistryGetValue(key, value):
try:
return _RegistryGetValueUsingWinReg(key, value)
except ImportError:
raise Exception('The python library _winreg not found.')
def GetVisualStudioVersion():
"""Return best available version of Visual Studio.
"""
supported_versions = list(MSVS_VERSIONS.keys())
# VS installed in depot_tools for Googlers
if bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1'))):
return supported_versions[0]
# 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:
# 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',
'BuildTools')):
available_versions.append(version)
break
if not available_versions:
raise Exception('No supported Visual Studio can be found.'
' Supported versions are: %s.' % supported_versions_str)
return available_versions[0]
def DetectVisualStudioPath():
"""Return path to the installed Visual Studio.
"""
# Note that this code is used from
# build/toolchain/win/setup_toolchain.py as well.
version_as_year = GetVisualStudioVersion()
# 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),
os.path.expandvars('%ProgramFiles(x86)%' +
'/Microsoft Visual Studio/%s/BuildTools' %
version_as_year)):
if path and os.path.exists(path):
return path
raise Exception('Visual Studio Version %s not found.' % version_as_year)
def _CopyRuntimeImpl(target, source, verbose=True):
"""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
abs(os.stat(target).st_mtime - os.stat(source).st_mtime) >= 0.01)):
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):
# 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)
# 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
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
def _CopyUCRTRuntime(target_dir, source_dir, target_cpu, suffix):
"""Copy both the msvcp and vccorlib runtime DLLs, only if the target doesn't
exist, but the target directory does exist."""
if target_cpu == 'arm64':
# Windows ARM64 VCRuntime is located at {toolchain_root}/VC/Redist/MSVC/
# {x.y.z}/[debug_nonredist/]arm64/Microsoft.VC14x.CRT/.
# Select VC toolset directory based on Visual Studio version
vc_redist_root = FindVCRedistRoot()
if suffix.startswith('.'):
vc_toolset_dir = 'Microsoft.{}.CRT' \
.format(MSVC_TOOLSET_VERSION[GetVisualStudioVersion()])
source_dir = os.path.join(vc_redist_root,
'arm64', vc_toolset_dir)
else:
vc_toolset_dir = 'Microsoft.{}.DebugCRT' \
.format(MSVC_TOOLSET_VERSION[GetVisualStudioVersion()])
source_dir = os.path.join(vc_redist_root, 'debug_nonredist',
'arm64', vc_toolset_dir)
file_parts = ('msvcp140', 'vccorlib140', 'vcruntime140')
if target_cpu == 'x64' and GetVisualStudioVersion() != '2017':
file_parts = file_parts + ('vcruntime140_1', )
for file_part in file_parts:
dll = file_part + suffix
target = os.path.join(target_dir, dll)
source = os.path.join(source_dir, dll)
_CopyRuntimeImpl(target, source)
# 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.
win_sdk_dir = os.path.normpath(
os.environ.get('WINDOWSSDKDIR',
Reland "Fixed SDK lookup for non C:\ Windows installation." This reverts commit 864136ef9686128f4afbfe6146cd3e2d08182d52. Reason for revert: While it seems this did trigger the cdb failures in crbug.com/846313, it was not the root cause and reverting it didn't actually help. Original change's description: > Revert "Fixed SDK lookup for non C:\ Windows installation." > > This reverts commit 57fd44c74e13be05a3091976f9bcee39ee8f703e. > > Reason for revert: suspect for messing up symbols on Win7 bot > @ crbug.com/846313 > > Original change's description: > > Fixed SDK lookup for non C:\ Windows installation. > > > > Bug: None > > Change-Id: Ia0aa186d1d39b1beac8ce0152683f774ad5d2eaf > > Reviewed-on: https://chromium-review.googlesource.com/1066065 > > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > > Commit-Queue: Jochen Eisinger <jochen@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#561063} > > TBR=jochen@chromium.org,yura.yaroshevich@gmail.com > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: 846313 > Change-Id: Id93a965aea5555961c539d47e05e79410894eff8 > Reviewed-on: https://chromium-review.googlesource.com/1072307 > Commit-Queue: Gabriel Charette <gab@chromium.org> > Reviewed-by: Gabriel Charette <gab@chromium.org> > Cr-Commit-Position: refs/heads/master@{#561609} TBR=gab@chromium.org,jochen@chromium.org,yura.yaroshevich@gmail.com Bug: 846313 Change-Id: I9955a47bbe8a81a0dcf7befebfc422560f8a1cc4 Reviewed-on: https://chromium-review.googlesource.com/1073314 Reviewed-by: Hans Wennborg <hans@chromium.org> Commit-Queue: Hans Wennborg <hans@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#561873} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 2e7257da41fbc81029fae5f306ae8123ec975f0c
2018-05-25 17:41:24 +03:00
os.path.expandvars('%ProgramFiles(x86)%'
'\\Windows Kits\\10')))
# ARM64 doesn't have a redist for the ucrt DLLs because they are always
# present in the OS.
if target_cpu != 'arm64':
# 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')
version_dirs = glob.glob(os.path.join(redist_dir, '10.*'))
if len(version_dirs) > 0:
_SortByHighestVersionNumberFirst(version_dirs)
redist_dir = version_dirs[0]
ucrt_dll_dirs = os.path.join(redist_dir, 'ucrt', 'DLLs', target_cpu)
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('.'):
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.
_SortByHighestVersionNumberFirst(sdk_bin_sub_dirs)
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
if re.match(r'10\.\d+\.\d+\.\d+', directory):
source_dir = os.path.join(sdk_redist_root_version, target_cpu, 'ucrt')
break
_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
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.
"""
SetEnvironmentAndGetRuntimeDllDirs()
assert ('GYP_MSVS_OVERRIDE_PATH' in os.environ)
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.
_SortByHighestVersionNumberFirst(vc_component_msvc_contents)
for directory in vc_component_msvc_contents:
if not os.path.isdir(os.path.join(vc_component_msvc_root, directory)):
continue
if re.match(r'14\.\d+\.\d+', directory):
return os.path.join(vc_component_msvc_root, directory)
raise Exception('Unable to find the VC %s directory.' % component)
def FindVCRedistRoot():
"""In >=VS2017, Redist binaries are located in
{toolchain_root}/VC/Redist/MSVC/{x.y.z}/{target_cpu}/.
This returns the '{toolchain_root}/VC/Redist/MSVC/{x.y.z}/' path.
"""
return FindVCComponentRoot('Redist')
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 2015, 2017 and 2019."""
suffix = 'd.dll' if debug else '.dll'
# VS 2015, 2017 and 2019 use the same CRT DLLs.
_CopyUCRTRuntime(target_dir, source_dir, target_cpu, 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
def CopyDlls(target_dir, configuration, target_cpu):
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
"""Copy the VS runtime DLLs into the requested directory as needed.
configuration is one of 'Debug' or 'Release'.
target_cpu is one of 'x86', '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.
"""
vs_runtime_dll_dirs = SetEnvironmentAndGetRuntimeDllDirs()
if not vs_runtime_dll_dirs:
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
return
x64_runtime, x86_runtime, 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)
_CopyRuntime(target_dir, runtime_dir, target_cpu, debug=False)
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
if configuration == 'Debug':
_CopyRuntime(target_dir, runtime_dir, target_cpu, debug=True)
_CopyDebugger(target_dir, target_cpu)
def _CopyDebugger(target_dir, target_cpu):
"""Copy dbghelp.dll and dbgcore.dll into the requested directory as needed.
target_cpu is one of 'x86', 'x64' or 'arm64'.
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.
dbgcore.dll is needed when using some functions from dbghelp.dll (like
MinidumpWriteDump).
"""
win_sdk_dir = SetEnvironmentAndGetSDKDir()
if not win_sdk_dir:
return
# 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)]
# The UCRT is not a redistributable component on arm64.
if target_cpu != 'arm64':
debug_files.extend([('api-ms-win-downlevel-kernel32-l2-1-0.dll', False),
('api-ms-win-eventing-provider-l1-1-0.dll', False)])
for debug_file, is_optional in debug_files:
full_path = os.path.join(win_sdk_dir, 'Debuggers', target_cpu, debug_file)
if not os.path.exists(full_path):
if is_optional:
continue
else:
raise Exception('%s not found in "%s"\r\nYou must install'
'Windows 10 SDK version 10.0.19041.0 including the '
'"Debugging Tools for Windows" feature.' %
(debug_file, full_path))
target_path = os.path.join(target_dir, debug_file)
_CopyRuntimeImpl(target_path, full_path)
def _GetDesiredVsToolchainHashes():
"""Load a list of SHA1s corresponding to the toolchains that we want installed
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.
"""
Reland "Reland "New toolchain for Windows 10 19041 SDK"" This reverts commit ed0697fcf0f958c1bc6643d911d99b1d9b52ed9b. Reason for revert: crrev.com/c/2255126 fixes the midl.py failures on Windows 7 class OSes and crrev.com/c/2260933 rolls in a native_client change that stops preprocessing .S files with cl.exe. With those changes cl.exe is not used in the build on Windows 7 anymore and that should let this toolchain land. This change now locks the SDK version to 10.0.19041.0 for users who don't use a packaged toolchain which ensures consistency and should simplify future toolchain upgrades. This change was tested with the lock as shown and with a lock to a previous SDK version. Original change's description: > Revert "Reland "New toolchain for Windows 10 19041 SDK"" > > This reverts commit 424526a023397ebbe6555ea27b82f66c137e8022. > > Reason for revert: win64-chrome build succeeded (progress) but > win32-chrome builder failed with a previously unseen error, shown > here: > > [170/58214] ACTION //remoting/host/win:remoting_lib_idl_idl_action(//build/toolchain/win:win_clang_x86) > FAILED: gen/remoting/host/win/chromoting_lib.h gen/remoting/host/win/chromoting_lib.dlldata.c gen/remoting/host/win/chromoting_lib_i.c gen/remoting/host/win/chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.tlb > c:\b\s\w\ir\cipd_bin_packages\cpython\bin\python.exe ../../build/toolchain/win/midl.py environment.x86 c:/b/s/w/ir/cache/builder/src/third_party/win_build_output/midl/remoting/host/win gen/remoting/host/win 7219b935-4873-533b-9ce1-20c9e9b12def chromoting_lib.tlb chromoting_lib.h chromoting_lib.dlldata.c chromoting_lib_i.c chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.idl /char signed /env win32 /Oicf > cl : Command line error D8027 : cannot execute 'c:\b\s\w\ir\cache\builder\src\third_party\depot_tools\win_toolchain\vs_files\a687d8e2e4114d9015eb550e1b156af21381faac\win_sdk\bin\..\..\VC\Tools\MSVC\14.26.28801\bin\HostX64\x86\c1.dll' > midl : command line error MIDL1003 : error returned by the C preprocessor (2) > > Original change's description: > > Reland "New toolchain for Windows 10 19041 SDK" > > > > This is a reland of 4a4f53a7f22f9058b2f171fc46bc5657bbe83e45 > > > > The original patch would fail to build on the mksnapshot step on > > Windows 7 (and server equivalents). This was due to two APISet DLLs > > that are required for the new dbghelp.dll. This change copies the two > > of them during gn gen. In order to have them as part of the isolates > > for cdb and in order to avoid dangerous ambiguity they are now > > required, which means that when this change lands the new SDK will be > > required. This is slightly disruptive for developers who aren't using > > our toolchain, but it seems unavoidable. > > > > Developers who don't have the latest SDK installed will hit this error > > message during gn gen: > > > > Exception: api-ms-win-downlevel-kernel32-l2-1-0.dll not found in "..." > > You must install the "Debugging Tools for Windows" feature from the > > Windows 10 SDK, the 10.0.19041.0 version. > > > > Original change's description: > > > New toolchain for Windows 10 19041 SDK > > > > > > This change updates the toolchain package used to build Chromium with > > > the 10.0.19041.0 (2020-04) SDK and VS 16.6.1. The d3dcompiler_47.dll > > > DLLs for x86 and x64 were swapped out for the 10.0.17134 versions (as > > > usual). > > > > > > The Debuggers directory was not swapped out this time because the > > > problem with loading dbghelp.dll on Windows 7 > > > (https://crbug.com/1021650) has been resolved. > > > > > > The output for the cdb copy step was updated because one additional UCRT > > > DLL is now copied. > > > > > > Packaging was done on a Windows Server 2019 VM, cleanly created for this > > > purpose. > > > > > > The package was created by downloading the VS Professional 2019 > > > installer from https://visualstudio.microsoft.com/downloads/ > > > (free trial, not preview) and then running the installer like this: > > > > > > $ PATH_TO_INSTALLER.EXE ^ > > > --add Microsoft.VisualStudio.Workload.NativeDesktop ^ > > > --add Microsoft.VisualStudio.Component.VC.ATLMFC ^ > > > --add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^ > > > --add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^ > > > --includeRecommended --passive > > > > > > Then the latest Windows 10 SDK was downloaded and installed from > > > https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/ > > > > > > Then the packaging script was run like this: > > > > > > python3 depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.19041.0 > > > > > > Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid > > > shipping that (https://crbug.com/920704) the final packaging step was to > > > unzip the package, copy over the two copies of that DLL from the > > > previous toolchain's win_sdk\Redist, and then repackage the toolchain > > > with: > > > > python3 package_from_installed.py --repackage=<full-path-to-toolchain-dir> > > > > > > UWP and ARM64 support and Python 3 compatibility were previously added > > > to package_from_installed.py. > > > > > > Future changes will require the new SDK, but for now the previous SDK > > > can also be used to build Chromium. > > > > > > The failures on the win*msvc* bots are unrelated. This was proven by > > > creating crrev.com/c/2245914 which is a NOP toolchain test. The existing > > > toolchain was repackaged with a single text file added and that caused > > > identical failures. > > > > > > Bug: 920704, 1014701, 1021650, 1089996 > > > Change-Id: Ie496354582458aa8c1292ed4ef63d949ee2eb15d > > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225224 > > > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > > > Reviewed-by: Henrik Andreasson <henrika@chromium.org> > > > Reviewed-by: Jamie Madill <jmadill@chromium.org> > > > Reviewed-by: Nico Weber <thakis@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#778924} > > > > Bug: 920704, 1014701, 1021650, 1089996, 1095767 > > Change-Id: I75e7653d57964e2929106e41b3f50594d3969e5f > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249394 > > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > > Reviewed-by: Jesse McKenna <jessemckenna@google.com> > > Reviewed-by: Jamie Madill <jmadill@chromium.org> > > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#780431} > > TBR=dcheng@chromium.org,henrika@webrtc.org,thakis@chromium.org,brucedawson@chromium.org,henrika@chromium.org,jessemckenna@google.com,jmadill@chromium.org > > Change-Id: If00e3865e66d9071189b2aca28f7541ecbdc6486 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: 920704, 1014701, 1021650, 1089996, 1095767 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255558 > Reviewed-by: Bruce Dawson <brucedawson@chromium.org> > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#780467} TBR=dcheng@chromium.org,henrika@webrtc.org,thakis@chromium.org,brucedawson@chromium.org,henrika@chromium.org,jessemckenna@google.com,jmadill@chromium.org Bug: 920704, 1014701, 1021650, 1089996, 1095767 Change-Id: I68e4c246ee903ba48d59b3bdea913ea3975c49d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255527 Reviewed-by: Nico Weber <thakis@chromium.org> Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Henrik Andreasson <henrika@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#781663} GitOrigin-RevId: a90d6d8f4ed7c9302f9329d205d0dc585997ab8f
2020-06-24 05:03:38 +03:00
# VS 2019 16.61 with 10.0.19041 SDK, and 10.0.17134 version of
# d3dcompiler_47.dll, with ARM64 libraries and UWP support.
# See go/chromium-msvc-toolchain for instructions about how to update the
# toolchain.
Reland "Reland "New toolchain for Windows 10 19041 SDK"" This reverts commit ed0697fcf0f958c1bc6643d911d99b1d9b52ed9b. Reason for revert: crrev.com/c/2255126 fixes the midl.py failures on Windows 7 class OSes and crrev.com/c/2260933 rolls in a native_client change that stops preprocessing .S files with cl.exe. With those changes cl.exe is not used in the build on Windows 7 anymore and that should let this toolchain land. This change now locks the SDK version to 10.0.19041.0 for users who don't use a packaged toolchain which ensures consistency and should simplify future toolchain upgrades. This change was tested with the lock as shown and with a lock to a previous SDK version. Original change's description: > Revert "Reland "New toolchain for Windows 10 19041 SDK"" > > This reverts commit 424526a023397ebbe6555ea27b82f66c137e8022. > > Reason for revert: win64-chrome build succeeded (progress) but > win32-chrome builder failed with a previously unseen error, shown > here: > > [170/58214] ACTION //remoting/host/win:remoting_lib_idl_idl_action(//build/toolchain/win:win_clang_x86) > FAILED: gen/remoting/host/win/chromoting_lib.h gen/remoting/host/win/chromoting_lib.dlldata.c gen/remoting/host/win/chromoting_lib_i.c gen/remoting/host/win/chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.tlb > c:\b\s\w\ir\cipd_bin_packages\cpython\bin\python.exe ../../build/toolchain/win/midl.py environment.x86 c:/b/s/w/ir/cache/builder/src/third_party/win_build_output/midl/remoting/host/win gen/remoting/host/win 7219b935-4873-533b-9ce1-20c9e9b12def chromoting_lib.tlb chromoting_lib.h chromoting_lib.dlldata.c chromoting_lib_i.c chromoting_lib_p.c gen/remoting/host/win/chromoting_lib.idl /char signed /env win32 /Oicf > cl : Command line error D8027 : cannot execute 'c:\b\s\w\ir\cache\builder\src\third_party\depot_tools\win_toolchain\vs_files\a687d8e2e4114d9015eb550e1b156af21381faac\win_sdk\bin\..\..\VC\Tools\MSVC\14.26.28801\bin\HostX64\x86\c1.dll' > midl : command line error MIDL1003 : error returned by the C preprocessor (2) > > Original change's description: > > Reland "New toolchain for Windows 10 19041 SDK" > > > > This is a reland of 4a4f53a7f22f9058b2f171fc46bc5657bbe83e45 > > > > The original patch would fail to build on the mksnapshot step on > > Windows 7 (and server equivalents). This was due to two APISet DLLs > > that are required for the new dbghelp.dll. This change copies the two > > of them during gn gen. In order to have them as part of the isolates > > for cdb and in order to avoid dangerous ambiguity they are now > > required, which means that when this change lands the new SDK will be > > required. This is slightly disruptive for developers who aren't using > > our toolchain, but it seems unavoidable. > > > > Developers who don't have the latest SDK installed will hit this error > > message during gn gen: > > > > Exception: api-ms-win-downlevel-kernel32-l2-1-0.dll not found in "..." > > You must install the "Debugging Tools for Windows" feature from the > > Windows 10 SDK, the 10.0.19041.0 version. > > > > Original change's description: > > > New toolchain for Windows 10 19041 SDK > > > > > > This change updates the toolchain package used to build Chromium with > > > the 10.0.19041.0 (2020-04) SDK and VS 16.6.1. The d3dcompiler_47.dll > > > DLLs for x86 and x64 were swapped out for the 10.0.17134 versions (as > > > usual). > > > > > > The Debuggers directory was not swapped out this time because the > > > problem with loading dbghelp.dll on Windows 7 > > > (https://crbug.com/1021650) has been resolved. > > > > > > The output for the cdb copy step was updated because one additional UCRT > > > DLL is now copied. > > > > > > Packaging was done on a Windows Server 2019 VM, cleanly created for this > > > purpose. > > > > > > The package was created by downloading the VS Professional 2019 > > > installer from https://visualstudio.microsoft.com/downloads/ > > > (free trial, not preview) and then running the installer like this: > > > > > > $ PATH_TO_INSTALLER.EXE ^ > > > --add Microsoft.VisualStudio.Workload.NativeDesktop ^ > > > --add Microsoft.VisualStudio.Component.VC.ATLMFC ^ > > > --add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^ > > > --add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^ > > > --includeRecommended --passive > > > > > > Then the latest Windows 10 SDK was downloaded and installed from > > > https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/ > > > > > > Then the packaging script was run like this: > > > > > > python3 depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.19041.0 > > > > > > Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid > > > shipping that (https://crbug.com/920704) the final packaging step was to > > > unzip the package, copy over the two copies of that DLL from the > > > previous toolchain's win_sdk\Redist, and then repackage the toolchain > > > with: > > > > python3 package_from_installed.py --repackage=<full-path-to-toolchain-dir> > > > > > > UWP and ARM64 support and Python 3 compatibility were previously added > > > to package_from_installed.py. > > > > > > Future changes will require the new SDK, but for now the previous SDK > > > can also be used to build Chromium. > > > > > > The failures on the win*msvc* bots are unrelated. This was proven by > > > creating crrev.com/c/2245914 which is a NOP toolchain test. The existing > > > toolchain was repackaged with a single text file added and that caused > > > identical failures. > > > > > > Bug: 920704, 1014701, 1021650, 1089996 > > > Change-Id: Ie496354582458aa8c1292ed4ef63d949ee2eb15d > > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225224 > > > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > > > Reviewed-by: Henrik Andreasson <henrika@chromium.org> > > > Reviewed-by: Jamie Madill <jmadill@chromium.org> > > > Reviewed-by: Nico Weber <thakis@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#778924} > > > > Bug: 920704, 1014701, 1021650, 1089996, 1095767 > > Change-Id: I75e7653d57964e2929106e41b3f50594d3969e5f > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249394 > > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > > Reviewed-by: Jesse McKenna <jessemckenna@google.com> > > Reviewed-by: Jamie Madill <jmadill@chromium.org> > > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#780431} > > TBR=dcheng@chromium.org,henrika@webrtc.org,thakis@chromium.org,brucedawson@chromium.org,henrika@chromium.org,jessemckenna@google.com,jmadill@chromium.org > > Change-Id: If00e3865e66d9071189b2aca28f7541ecbdc6486 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: 920704, 1014701, 1021650, 1089996, 1095767 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255558 > Reviewed-by: Bruce Dawson <brucedawson@chromium.org> > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#780467} TBR=dcheng@chromium.org,henrika@webrtc.org,thakis@chromium.org,brucedawson@chromium.org,henrika@chromium.org,jessemckenna@google.com,jmadill@chromium.org Bug: 920704, 1014701, 1021650, 1089996, 1095767 Change-Id: I68e4c246ee903ba48d59b3bdea913ea3975c49d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2255527 Reviewed-by: Nico Weber <thakis@chromium.org> Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Henrik Andreasson <henrika@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#781663} GitOrigin-RevId: a90d6d8f4ed7c9302f9329d205d0dc585997ab8f
2020-06-24 05:03:38 +03:00
toolchain_hash = 'a687d8e2e4114d9015eb550e1b156af21381faac'
Switch to VS 2019. Goma no longer supports cl.exe and the cl.exe version update in this CL hasn't been uploaded to goma's servers. Everyone who has bots that use cl.exe must make sure that these bots don't use goma before rolling this CL in. This change switches the MSVC toolchain to VS 2019 16.3.29324. Windows SDK is mostly 10.0.18362 Debuggers from 10.0.17763 d3dcompiler_47.dll from 10.0.17134 The instructions for the previous package are included below: Packaging was done on a Windows Server 2019 VM, cleanly created for this purpose. The package was created by downloading VS 2019 Update 3.29324, from https://visualstudio.microsoft.com/downloads/ and downloading the 16.3 Visual Studio Professional 2019, and then running the installer like this: $ PATH_TO_INSTALLER.EXE ^ --add Microsoft.VisualStudio.Workload.NativeDesktop ^ --add Microsoft.VisualStudio.Component.VC.ATLMFC ^ --add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^ --add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^ --includeRecommended --passive Then the 10.0.18362.0 SDK was installed from: https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk. Then Add or Remove Programs was used to modify the 10.0.18362.0 SDK to add the Debuggers package. Then the packaging script was run like this: python depot_tools\win_toolchain\package_from_installed.py 2019 -w 10.0.18362.0 Since the new d3dcompiler_47.dll uses the UCRT and we want to avoid shipping that the final packaging step was to unzip the package, copy over the two copies of that DLL from win_sdk\Redist, replace the Debuggers directory with the 10.0.17763 SDK, and then repackage the toolchain with: > python package_from_installed.py --repackage=<full-path-to-toolchain-dir> Bug: 1006238 Change-Id: I623632bd72f018a74ab513d2c79e89199915e647 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1836195 Reviewed-by: Nico Weber <thakis@chromium.org> Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Commit-Queue: Mirko Bonadei <mbonadei@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#704569} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 8e82c6ab1bc2223fa25f1a127b65071d2d58ae36
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)]
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
Refuse to download new toolchain during gn gen This change relies on the depot_tools change crrev.com/c/1439805 Chromium and v8 have rolled to a new enough version of depot_tools to support this script and Angle always uses the latest version of depot_tools so there shouldn't be any script-mismatch problems caused by landing this. The toolchain used to build Chrome is supposed to be updated during "gclient runhooks" but currently if that doesn't happen (if GYP_MSVS_VERSION is changed but "gclient runhooks" isn't run) then the update will be tried during "gn gen". That works badly. It leads to attempts to parse the update output as toolchain information, it can lead to the update happening in parallel, and is generally a bad idea. This change passes --no-download to depot_tools\win_toolchain\get_toolchain_if_necessary.py when 'update' is not the command being processed so that the depot_tools script will no that it should only configure the toolchain, not try downloading it. This also prevents attempts to update the toolchain when running tools\win\setenv.bat This was tested by forcing an updated to VS 2019 and confirming that the new behavior is as desired (failing with an informative message when appropriate, working when appropriate). This includes testing that using the local toolchain (if installed) works with this change. See crrev.com/c/1426397, the CL that was used for testing on the bots. Both bugs suggest that our bots sometimes don't update the toolchain when they are supposed to. If that is the case then this change will help to flush out those bugs so that they can be fixed. Bug: 584393,662325 Change-Id: I0ef671977ea59b4f3368827c5b5ffe50ed6602f7 Reviewed-on: https://chromium-review.googlesource.com/c/1444031 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#627513} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 060aa690a1abce245184e1f251e9414a0eb8637f
2019-01-30 21:48:35 +03:00
def Update(force=False, no_download=False):
"""Requests an update of the toolchain to the specific hashes we have at
this revision. The update outputs a .json of the various configuration
information required to pass to gyp which we use in |GetToolchainDir()|.
Refuse to download new toolchain during gn gen This change relies on the depot_tools change crrev.com/c/1439805 Chromium and v8 have rolled to a new enough version of depot_tools to support this script and Angle always uses the latest version of depot_tools so there shouldn't be any script-mismatch problems caused by landing this. The toolchain used to build Chrome is supposed to be updated during "gclient runhooks" but currently if that doesn't happen (if GYP_MSVS_VERSION is changed but "gclient runhooks" isn't run) then the update will be tried during "gn gen". That works badly. It leads to attempts to parse the update output as toolchain information, it can lead to the update happening in parallel, and is generally a bad idea. This change passes --no-download to depot_tools\win_toolchain\get_toolchain_if_necessary.py when 'update' is not the command being processed so that the depot_tools script will no that it should only configure the toolchain, not try downloading it. This also prevents attempts to update the toolchain when running tools\win\setenv.bat This was tested by forcing an updated to VS 2019 and confirming that the new behavior is as desired (failing with an informative message when appropriate, working when appropriate). This includes testing that using the local toolchain (if installed) works with this change. See crrev.com/c/1426397, the CL that was used for testing on the bots. Both bugs suggest that our bots sometimes don't update the toolchain when they are supposed to. If that is the case then this change will help to flush out those bugs so that they can be fixed. Bug: 584393,662325 Change-Id: I0ef671977ea59b4f3368827c5b5ffe50ed6602f7 Reviewed-on: https://chromium-review.googlesource.com/c/1444031 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#627513} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 060aa690a1abce245184e1f251e9414a0eb8637f
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.
"""
if force != False and force != '--force':
print('Unknown parameter "%s"' % force, file=sys.stderr)
return 1
if force == '--force' or os.path.exists(json_data_file):
force = True
depot_tools_win_toolchain = \
bool(int(os.environ.get('DEPOT_TOOLS_WIN_TOOLCHAIN', '1')))
if (_HostIsWindows() or force) and depot_tools_win_toolchain:
import find_depot_tools
depot_tools_path = find_depot_tools.add_depot_tools_to_path()
# 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')
# For testing this block, unmount existing mounts with
# fusermount -u third_party/depot_tools/win_toolchain/vs_files
if sys.platform.startswith('linux') and not os.path.ismount(toolchain_dir):
import distutils.spawn
ciopfs = distutils.spawn.find_executable('ciopfs')
if not ciopfs:
# ciopfs not found in PATH; try the one downloaded from the DEPS hook.
ciopfs = os.path.join(script_dir, 'ciopfs')
if not os.path.isdir(toolchain_dir):
os.mkdir(toolchain_dir)
if not os.path.isdir(toolchain_dir + '.ciopfs'):
os.mkdir(toolchain_dir + '.ciopfs')
# 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])
get_toolchain_args = [
sys.executable,
os.path.join(depot_tools_path,
'win_toolchain',
'get_toolchain_if_necessary.py'),
'--output-json', json_data_file,
] + _GetDesiredVsToolchainHashes()
if force:
get_toolchain_args.append('--force')
Refuse to download new toolchain during gn gen This change relies on the depot_tools change crrev.com/c/1439805 Chromium and v8 have rolled to a new enough version of depot_tools to support this script and Angle always uses the latest version of depot_tools so there shouldn't be any script-mismatch problems caused by landing this. The toolchain used to build Chrome is supposed to be updated during "gclient runhooks" but currently if that doesn't happen (if GYP_MSVS_VERSION is changed but "gclient runhooks" isn't run) then the update will be tried during "gn gen". That works badly. It leads to attempts to parse the update output as toolchain information, it can lead to the update happening in parallel, and is generally a bad idea. This change passes --no-download to depot_tools\win_toolchain\get_toolchain_if_necessary.py when 'update' is not the command being processed so that the depot_tools script will no that it should only configure the toolchain, not try downloading it. This also prevents attempts to update the toolchain when running tools\win\setenv.bat This was tested by forcing an updated to VS 2019 and confirming that the new behavior is as desired (failing with an informative message when appropriate, working when appropriate). This includes testing that using the local toolchain (if installed) works with this change. See crrev.com/c/1426397, the CL that was used for testing on the bots. Both bugs suggest that our bots sometimes don't update the toolchain when they are supposed to. If that is the case then this change will help to flush out those bugs so that they can be fixed. Bug: 584393,662325 Change-Id: I0ef671977ea59b4f3368827c5b5ffe50ed6602f7 Reviewed-on: https://chromium-review.googlesource.com/c/1444031 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#627513} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 060aa690a1abce245184e1f251e9414a0eb8637f
2019-01-30 21:48:35 +03:00
if no_download:
get_toolchain_args.append('--no-download')
subprocess.check_call(get_toolchain_args)
return 0
def NormalizePath(path):
while path.endswith('\\'):
path = path[:-1]
return path
def SetEnvironmentAndGetSDKDir():
"""Gets location information about the current sdk (must have been
previously updated by 'update'). This is used for the GN build."""
SetEnvironmentAndGetRuntimeDllDirs()
# If WINDOWSSDKDIR is not set, search the default SDK path and set it.
if not 'WINDOWSSDKDIR' in os.environ:
WinUWP store application support is out of date This is required to support building Microsoft's WinUWP store application version of WebRTC. vs_toolchain.py - needed to perform environment variable expansion for "Program Files(x86)" to correctly identify Visual Studio installation location config/BUILD.gn - remove delayimp.lib, kernel32.lib and ole32.lib from store applications (instead requires dloadhelper.lib/WindowsApp.lib must be used) BUILDCONFIG.gn - Do not use clang when compiling Windows UWP targets; - Added declare_args for is_target_winuwp rather and stripped multi defined variations of the host_os/current_os == "winrt_10", "winrt_81", "winrt_81_phone" that heavily polluted the platform / target selections (as the current targeting methodology is incorrect anyway). The host_os/current_os is always be "win" and only the target should be Windows UWP / store applications based on the target_os == "winuwp" rather than all the flavors of UWP. - Added filter for _winuwp source files (separate from just windows) - Added default configs for desktop vs store applications to correctly set the defines according to the desktop vs store targets config/win/BUILD.gn - The Windows UWP versioning assumes to be Windows 10 / store app now although a updated GN allows for targeting older Windows UWP versions/SDKs/device families. This allows the definitions for the various application support versioning and application families required for UWP to be set. - The linker calls vsvarsall.bat to be executed via toolchain/win/setup_toolchain.py in order to correctly identify the correct linker library path information for Windows store SDK targets. The hard coded and assumed library paths are fixed in all cases to be discovered from the tooling for forward future platform support in all cases. - Added ARM linkage definitions for the Windows ARM CPU required for properly targeting all three CPUs (x86, x64, arm) for universal store binaries. - Added the proper family C++/C defines required to target the various Windows store application types currently offered for Windows UWP store applications. toolchain/win/BUILD.gn - The name to support the storage of the environment variables now is passed into the setup script to allow for easier extension of the CPUs and target combinations (arm, x64, x86 in the desktop vs store variations) - "desktop" vs "store" is now specified the setup for the correct toolchain targeting - Sets true/false for is_target_winuwp is dependent on the toolchain activated (so configurations will be set correctly when the toolchain is specified for host tool targets required for build tools vs finalized application targets) - Cleaned up the Windows RT section to properly support Windows UWP toolchains toolchain/win/setup_toolchain.py - the setup was missing the arm CPU for universal binaries required for the UWP platform - The calling of vcvarsall.bat was missing the "store" option for store applications and all the CPU offered - Added returning of linker paths by searching the library environments for well-known library files expected in each of the 3 library paths required "lib", "um" and "atlmfc" R=phoglund@google.com Bug: 812814 Change-Id: If1a6b1b1bc3ed940fc8e2ce726ac016e2491e61d Reviewed-on: https://chromium-review.googlesource.com/923161 Commit-Queue: Patrik Höglund <phoglund@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#545751} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: c5686578e8f519eeec50f574b284fbc12e6e15d8
2018-03-26 13:07:40 +03:00
default_sdk_path = os.path.expandvars('%ProgramFiles(x86)%'
'\\Windows Kits\\10')
if os.path.isdir(default_sdk_path):
os.environ['WINDOWSSDKDIR'] = default_sdk_path
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()
print('''vs_path = %s
sdk_path = %s
vs_version = %s
wdk_dir = %s
runtime_dirs = %s
''' % (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']))))
def main():
commands = {
'update': Update,
'get_toolchain_dir': GetToolchainDir,
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
'copy_dlls': CopyDlls,
}
if len(sys.argv) < 2 or sys.argv[1] not in commands:
print('Expected one of: %s' % ', '.join(commands), file=sys.stderr)
return 1
Rework win_toolchains a bit and copy the vs runtime DLLs as needed. In order to run both the visual studio tools and the binaries built by them (and ninja), we need to ensure that the VS runtime DLLs are available in the path. In the GYP build, we accomplish this by copying them into the Debug and Debug_x64 dirs as appropriate inside the gyp_chromium script. In the pure-GN build, then, things would be broken, so we need to modify the GN build to do the copy as well, or we need to inject a step somewhere that happens after GN runs but before Ninja tries to run (since none of the toolchain binaries will work). This patch accomplishes this by calling out to vs_toolchain.py to copy the DLLs as neede when the toolchain is defined. This is somewhat less than ideal (makes 'gn gen' slower) but seems better than forcing devs to have to run an additional command. In addition, the GYP build writes targets into Debug and Debug_x64 concurrently. This doesn't really carry over into GN correctly, and we probably only ever want to write targets into Debug and Debug/64 (or some such). However, the way the toolchains are currently implemented, it's not clear if this really works and the interplay between 32-bit and 64-bit is weird (we apparently normally "force" 32-bit even if we set cpu_arch to 64-bit, and require you to specify force_win64). To work around this and make sure that we copy the right DLLs for the right arch into the outer Debug/ directory, this patch temporarily disables the cross-arch part of the build, forcing the host_toolchain to match the target_toolchain. This likely means that 'cpu_arch="x86"' works (the default), but the 'host' binaries like image_diff and mksnapshot will be compiled in 32-bit mode, not 64-bit mode. 'cpu_arch="x64" force_win64=true' should also work, and produce all-64-bit binaries. 'cpu_arch="x64"' does not work at all and won't until we can clean up the above stuff. R=scottmg@chromium.org, brettw@chromium.org BUG=430661 Review URL: https://codereview.chromium.org/722723004 Cr-Original-Commit-Position: refs/heads/master@{#304310} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 0b95195e49489b7a4d87048d2ce4b747173a5b8a
2014-11-15 03:09:14 +03:00
return commands[sys.argv[1]](*sys.argv[2:])
if __name__ == '__main__':
sys.exit(main())