|
|
Created:
4 years, 11 months ago by brucedawson Modified:
4 years, 11 months ago Reviewers:
scottmg CC:
chromium-reviews, dpranke+depot_tools_chromium.org, iannucci+depot_tools_chromium.org, pschmidt1 Base URL:
https://chromium.googlesource.com/chromium/tools/depot_tools.git@master Target Ref:
refs/heads/master Project:
depot_tools Visibility:
Public. |
DescriptionPackage/Install the Windows 10 Universal C Runtime for VS 2015
The VS 2015 tools require the Windows 10 Universal C Runtime, either
installed in C:\Windows or in every directory containing tools, or
dynamically linked executables created with VS 2015. Installing to
C:\Windows seems less error prone.
This is only applicable for Google developers and build machines that
don't have VS 2015 installed.
This updates the packaging script so that it packages the three
installers, and no longer packages the installed files (which vary
between operating systems anyway).
The installer is updated to check for the existence of one of the
Universal C Runtime files. If it isn't found then it detects the
version of Windows in order to select and run the correct installer.
I manually confirmed that, for instance, the installers for Windows 7
and Windows 2008 R2, were identical despite coming from different
download URLs.
If the installation fails because gclient runhooks is run non-elevated
then the developer will have to do a one-time manual install of the
update. A message will be printed indicating this.
BUG=440500
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=298286
Patch Set 1 #
Total comments: 14
Patch Set 2 : Adding packaging code and integrating installer code #Patch Set 3 : Remove debug code and sys.exit(0), and better Windows 10 handling #Patch Set 4 : Fix installer path! #
Total comments: 1
Patch Set 5 : Package ucrtbased.dll #
Total comments: 2
Patch Set 6 : Use _winreg, and add vctip.exe to kill list #
Total comments: 5
Patch Set 7 : Code review fixes #Patch Set 8 : Fix Windows 10 support and don't install for VS 2013 #
Total comments: 2
Patch Set 9 : Fix indent #Patch Set 10 : Use OSError instead of WindowsError for pylint on Linux #
Messages
Total messages: 31 (8 generated)
brucedawson@chromium.org changed reviewers: + scottmg@chromium.org
Scott, can you take a quick sanity-check look at this? It's not done (the .msu files aren't packaged, and this script isn't called from anywhere) but I wanted some feedback before I do that. I've done some basic testing and it appears to work. The output when run from a non-elevated command prompt when the CRT is not installed looks like this: C:\Windows\Sysnative\api-ms-win-crt-math-l1-1-0.dll does not exist - installing Running wusa.exe /quiet "Windows6.1-KB2999226-x64.msu" Traceback (most recent call last): File "c:\src\install.py", line 68, in <module> sys.exit(main()) File "c:\src\install.py", line 64, in main installer) Exception: Elevation required. You must manually install Windows6.1-KB2999226-x64.msu The full path to the correct .msu will be printed so installing it should be straightforward. This could also be part of one of the existing scripts, such as get_toolchain_if_necessary.py. That would probably be cleaner than having it as a separate script.
Yeah, looks good. I'd probably just inline it into get_toolchain_if_necessary or somewhere similar as you suggested. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... File win_toolchain/install_universal_c_runtime.py (right): https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:1: # Copyright 2014 The Chromium Authors. All rights reserved. 2016 https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:17: def GetInstallerName(): Two blank lines between top-level statements in Python. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:30: update = 'Windows6.1-KB2999226-x64.msu' Could probably just return X rather than than having update as a temporary. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:46: x64_path = os.path.join(r'C:\Windows', x64_path) WINDIR? Whatever. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:47: sample_crt_file = os.path.join(x64_path, 'api-ms-win-crt-math-l1-1-0.dll') Is 1-1-0 always going to be around in Win10+ forevermore? https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:53: print '%s does not exist - installing' % sample_crt_file '...installing Windows 10 Universal CRT' https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:63: raise Exception('Elevation required. You must manually install %s' % Instead of raise'ing here, a well formatted message that someone might see in the noisy spam of gclient runhooks where this will be encountered. print '-'*80 print print 'blah blah, you need to run the following command:' print ' wusa /quiet d:\full\path\to\x.msu' print print '-'*80 (The raise e for other errors is fine though.)
This is ready for a real review now, of both the update packaging and the updated installer. I've tried end-to-end testing with a package created on my dev machine and it works perfectly. This is what the output looks like when the installation fails. I think the message is sufficiently visible and clear, and the exception makes it impossible to ignore. If the developer copies/pastes the message to the command prompt (or pastes to the start menu, or wherever) then the update installs. The only thing I haven't done is creating a package on the VM - extracting the package on the VM works perfectly. ________ running 'c:\src\depot_tools\python276_bin\python.exe src/build/vs_toolchain.py update' in 'D:\src\chromium' C:\Windows\Sysnative\api-ms-win-crt-math-l1-1-0.dll does not exist - installing Windows 10 Universal C Runtime Running wusa.exe /quiet "c:\src\depot_tools\win_toolchain\vs_files\installers\Windows8.1-KB2999226-x64.msu" -------------------------------------------------------------------------------- Elevation required. You must manually install this update: c:\src\depot_tools\win_toolchain\vs_files\installers\Windows8.1-KB2999226-x64.msu -------------------------------------------------------------------------------- Traceback (most recent call last): File "c:\src\depot_tools\win_toolchain\get_toolchain_if_necessary.py", line 408, in <module> sys.exit(main()) File "c:\src\depot_tools\win_toolchain\get_toolchain_if_necessary.py", line 402, in main InstallUniversalCRTIfNeeded(abs_target_dir) File "c:\src\depot_tools\win_toolchain\get_toolchain_if_necessary.py", line 284, in InstallUniversalCRTIfNeeded installer) Exception: Elevation required. You must manually install c:\src\depot_tools\win_toolchain\vs_files\installers\Windows8.1-KB2999226-x64.msu Sending crash report ... https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... File win_toolchain/install_universal_c_runtime.py (right): https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:1: # Copyright 2014 The Chromium Authors. All rights reserved. On 2016/01/14 03:10:28, scottmg wrote: > 2016 Done. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:17: def GetInstallerName(): On 2016/01/14 03:10:28, scottmg wrote: > Two blank lines between top-level statements in Python. Done. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:30: update = 'Windows6.1-KB2999226-x64.msu' On 2016/01/14 03:10:28, scottmg wrote: > Could probably just return X rather than than having update as a temporary. Done. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:47: sample_crt_file = os.path.join(x64_path, 'api-ms-win-crt-math-l1-1-0.dll') On 2016/01/14 03:10:28, scottmg wrote: > Is 1-1-0 always going to be around in Win10+ forevermore? I don't know for sure. I think so. An alternative would be to call GetInstallerName() and if it returns None then early-out - that handles the Windows 10+ case. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:53: print '%s does not exist - installing' % sample_crt_file On 2016/01/14 03:10:28, scottmg wrote: > '...installing Windows 10 Universal CRT' Done. https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:63: raise Exception('Elevation required. You must manually install %s' % Are you suggesting not doing a raise at all? My assumption is that it is necessary to do a raise because otherwise the error won't be noticed at all. Or maybe failing in some other way would work, but I don't know what way that would be. BTW, the user doesn't need the 'wusa /quiet' - that's only needed for unattended installs of the update.
https://codereview.chromium.org/1588673004/diff/60001/win_toolchain/package_f... File win_toolchain/package_from_installed.py (left): https://codereview.chromium.org/1588673004/diff/60001/win_toolchain/package_f... win_toolchain/package_from_installed.py:162: 'ucrtbased.dll', Oh damn, I just remembered that I still need to package up ucrtbased.dll.
https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... File win_toolchain/install_universal_c_runtime.py (right): https://codereview.chromium.org/1588673004/diff/1/win_toolchain/install_unive... win_toolchain/install_universal_c_runtime.py:63: raise Exception('Elevation required. You must manually install %s' % On 2016/01/14 21:14:17, brucedawson wrote: > Are you suggesting not doing a raise at all? My assumption is that it is > necessary to do a raise because otherwise the error won't be noticed at all. Or > maybe failing in some other way would work, but I don't know what way that would > be. > > BTW, the user doesn't need the 'wusa /quiet' - that's only needed for unattended > installs of the update. I was suggesting print ...; system.exit(1) or something. People's eyes have a tendency to glaze over when they see a python stack dump and just post to chromium-dev. The current version looks fine though.
Otherwise, lgtm, modulo packaging stuff. https://codereview.chromium.org/1588673004/diff/80001/win_toolchain/get_toolc... File win_toolchain/get_toolchain_if_necessary.py (right): https://codereview.chromium.org/1588673004/diff/80001/win_toolchain/get_toolc... win_toolchain/get_toolchain_if_necessary.py:231: output = subprocess.check_output('reg query %s /v CurrentVersion' % key_name) Can you do this with https://docs.python.org/2/library/_winreg.html instead?
> I was suggesting print ...; system.exit(1) or something. People's eyes have a > tendency to glaze over when they see a python stack dump and just post to > chromium-dev. The current version looks fine though. I just tested sys.exit(1) and it doesn't help - the spew is still impenetrable and equally long (crash report, etc.). It actually makes the failure cause slightly less obvious, so I'm going to leave that part alone.
Switched to _winreg, added vctip.exe to the list of executables that must be killed, and added ucrtbased.dll back to the list of packaged files. Running VM packaging/unpackaging tests now. PTAL. https://codereview.chromium.org/1588673004/diff/80001/win_toolchain/get_toolc... File win_toolchain/get_toolchain_if_necessary.py (right): https://codereview.chromium.org/1588673004/diff/80001/win_toolchain/get_toolc... win_toolchain/get_toolchain_if_necessary.py:231: output = subprocess.check_output('reg query %s /v CurrentVersion' % key_name) On 2016/01/14 21:49:59, scottmg wrote: > Can you do this with https://docs.python.org/2/library/_winreg.html instead? Done.
Description was changed from ========== Install the Windows 10 Universal C Runtime if needed The VS 2015 tools require the Windows 10 Universal C Runtime, either installed in C:\Windows or in every directory containing tools, or dynamically linked executables created with VS 2015. Installing to C:\Windows seems less error prone. This is only applicable for Google developers and build machines that don't have VS 2015 installed. This script checks for the existence of one of the Universal C Runtime files. If it isn't found then it detects the version of Windows in order to select the correct installer, which is packaged with VS 2015 for Google developers. I manually confirmed that, for instance, the installers for Windows 7 and Windows 2008 R2, were identical despite coming from different download URLs. If the installation fails because gclient runhooks is run non-elevated then the developer will have to do a one-time manual install of the update. BUG=440500 ========== to ========== Package/Install the Windows 10 Universal C Runtime for VS 2015 The VS 2015 tools require the Windows 10 Universal C Runtime, either installed in C:\Windows or in every directory containing tools, or dynamically linked executables created with VS 2015. Installing to C:\Windows seems less error prone. This is only applicable for Google developers and build machines that don't have VS 2015 installed. This updates the packaging script so that it packages the three installers, and no longer packages the installed files (which vary between operating systems anyway). The installer is updated to check for the existence of one of the Universal C Runtime files. If it isn't found then it detects the version of Windows in order to select and run the correct installer. I manually confirmed that, for instance, the installers for Windows 7 and Windows 2008 R2, were identical despite coming from different download URLs. If the installation fails because gclient runhooks is run non-elevated then the developer will have to do a one-time manual install of the update. A message will be printed indicating this. BUG=440500 ==========
lgtm https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/get_tool... File win_toolchain/get_toolchain_if_necessary.py (right): https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/get_tool... win_toolchain/get_toolchain_if_necessary.py:356: 'vctip.exe', # compiler and tools experience improvement data uploader compiler -> Compiler and end with a '.'. https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/package_... File win_toolchain/package_from_installed.py (right): https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/package_... win_toolchain/package_from_installed.py:139: # and they must be downloaded to the current user's downloads directory. This is a bit weird, but OK. https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/package_... win_toolchain/package_from_installed.py:151: installer), Align to inside the (.
https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/get_tool... File win_toolchain/get_toolchain_if_necessary.py (right): https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/get_tool... win_toolchain/get_toolchain_if_necessary.py:356: 'vctip.exe', # compiler and tools experience improvement data uploader On 2016/01/14 22:45:11, scottmg wrote: > compiler -> Compiler and end with a '.'. Done. https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/package_... File win_toolchain/package_from_installed.py (right): https://codereview.chromium.org/1588673004/diff/100001/win_toolchain/package_... win_toolchain/package_from_installed.py:151: installer), On 2016/01/14 22:45:11, scottmg wrote: > Align to inside the (. You mean indent one more space? Done.
Testing on Windows 10 revealed that (yay Microsoft!) Windows 10 reports its version number in the registry as being the same as Windows 8.1. It's possible to detect the difference by looking at yet another registry key, but it's not needed because the UCRT is always installed on Windows 10, so this just required some comment changes. Windows 10 testing also revealed that the script needs to use ucrtbase.dll to detect whether the UCRT is installed - changed. The testing also revealed that the script was installing the UCRT even for VS 2013 builds! That was not intended - fixed. Ready to go now. PTAL at the latest changes to get_toolchain_if_necessary.py if you get a chance.
It's amazing what testing can reveal! :) On 2016/01/15 18:22:31, brucedawson wrote: > Testing on Windows 10 revealed that (yay Microsoft!) Windows 10 reports its > version number in the registry as being the same as Windows 8.1. It's possible > to detect the difference by looking at yet another registry key, but it's not > needed because the UCRT is always installed on Windows 10, so this just required > some comment changes. Sigh. Why! > > Windows 10 testing also revealed that the script needs to use ucrtbase.dll to > detect whether the UCRT is installed - changed. > > The testing also revealed that the script was installing the UCRT even for VS > 2013 builds! That was not intended - fixed. Oops, I should have noticed that. I guess it wouldn't have been so bad anyway. > > Ready to go now. > > PTAL at the latest changes to get_toolchain_if_necessary.py if you get a chance. lgtm
https://codereview.chromium.org/1588673004/diff/140001/win_toolchain/get_tool... File win_toolchain/get_toolchain_if_necessary.py (right): https://codereview.chromium.org/1588673004/diff/140001/win_toolchain/get_tool... win_toolchain/get_toolchain_if_necessary.py:267: sample_crt_file) The indent should be after the (, aligned with '.
Indent fixed. Committing. https://codereview.chromium.org/1588673004/diff/140001/win_toolchain/get_tool... File win_toolchain/get_toolchain_if_necessary.py (right): https://codereview.chromium.org/1588673004/diff/140001/win_toolchain/get_tool... win_toolchain/get_toolchain_if_necessary.py:267: sample_crt_file) On 2016/01/15 19:06:44, scottmg wrote: > The indent should be after the (, aligned with '. Done.
The CQ bit was checked by brucedawson@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from scottmg@chromium.org Link to the patchset: https://codereview.chromium.org/1588673004/#ps160001 (title: "Fix indent")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1588673004/160001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1588673004/160001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: depot_tools_presubmit on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/depot_tools_pre...)
The CQ bit was checked by brucedawson@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from scottmg@chromium.org Link to the patchset: https://codereview.chromium.org/1588673004/#ps180001 (title: "Use OSError instead of WindowsError for pylint on Linux")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1588673004/180001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1588673004/180001
Message was sent while issue was closed.
Description was changed from ========== Package/Install the Windows 10 Universal C Runtime for VS 2015 The VS 2015 tools require the Windows 10 Universal C Runtime, either installed in C:\Windows or in every directory containing tools, or dynamically linked executables created with VS 2015. Installing to C:\Windows seems less error prone. This is only applicable for Google developers and build machines that don't have VS 2015 installed. This updates the packaging script so that it packages the three installers, and no longer packages the installed files (which vary between operating systems anyway). The installer is updated to check for the existence of one of the Universal C Runtime files. If it isn't found then it detects the version of Windows in order to select and run the correct installer. I manually confirmed that, for instance, the installers for Windows 7 and Windows 2008 R2, were identical despite coming from different download URLs. If the installation fails because gclient runhooks is run non-elevated then the developer will have to do a one-time manual install of the update. A message will be printed indicating this. BUG=440500 ========== to ========== Package/Install the Windows 10 Universal C Runtime for VS 2015 The VS 2015 tools require the Windows 10 Universal C Runtime, either installed in C:\Windows or in every directory containing tools, or dynamically linked executables created with VS 2015. Installing to C:\Windows seems less error prone. This is only applicable for Google developers and build machines that don't have VS 2015 installed. This updates the packaging script so that it packages the three installers, and no longer packages the installed files (which vary between operating systems anyway). The installer is updated to check for the existence of one of the Universal C Runtime files. If it isn't found then it detects the version of Windows in order to select and run the correct installer. I manually confirmed that, for instance, the installers for Windows 7 and Windows 2008 R2, were identical despite coming from different download URLs. If the installation fails because gclient runhooks is run non-elevated then the developer will have to do a one-time manual install of the update. A message will be printed indicating this. BUG=440500 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=298286 ==========
Message was sent while issue was closed.
Committed patchset #10 (id:180001) as http://src.chromium.org/viewvc/chrome?view=rev&revision=298286
Message was sent while issue was closed.
On 2016/01/15 20:53:00, commit-bot: I haz the power wrote: > Committed patchset #10 (id:180001) as > http://src.chromium.org/viewvc/chrome?view=rev&revision=298286 I think this broke part of "gclient runhooks". The get_toolchain_if_necessary.py module imports "_winreg" which exists under vs2013_files but not anywhere else. Not sure why I'm the only one seeing it, perhaps because I'm a last hold-out for CygWin. I've removed the "import _winreg" line and "runhooks" seems to work but it's impossible to know if other things are broken.
Message was sent while issue was closed.
> I think this broke part of "gclient runhooks". The > get_toolchain_if_necessary.py module imports "_winreg" which exists under > vs2013_files but not anywhere else. > > Not sure why I'm the only one seeing it, perhaps because I'm a last hold-out for > CygWin. > > I've removed the "import _winreg" line and "runhooks" seems to work but it's > impossible to know if other things are broken. I would assume that CygWin is the difference. I'm not sure where in vs2013_files _winreg is - can you explain? I had a different version of GetInstallerName() that used reg.exe instead of _winreg. Can you try pasting this in to see if it works? It's a bit inelegant using a subprocess to read a registry key, but it does work. def GetInstallerName(): """Return the name of the Windows 10 Universal C Runtime installer for the current platform, or None if installer is not needed or not applicable. The registry has to be used instead of sys.getwindowsversion() because Python 2.7 is only manifested as being compatible up to Windows 8, so the version APIs helpfully return a maximum of 6.2 (Windows 8). """ ver_re = re.compile('.*REG_SZ * (\d+)\.(\d+)') key_name = '"HKLM\Software\Microsoft\Windows NT\CurrentVersion"' output = subprocess.check_output('reg query %s /v CurrentVersion' % key_name) match = ver_re.match(output.replace('\n', ' ')) if match.groups() == ('6', '1'): # Windows 7 and Windows Server 2008 R2 return 'Windows6.1-KB2999226-x64.msu' elif match.groups() == ('6', '2'): # Windows 8 and Windows Server 2012 return 'Windows8-RT-KB2999226-x64.msu' elif match.groups() == ('6', '3'): # Windows 8.1 and Windows Server 2012 R2, or Windows 10 return 'Windows8.1-KB2999226-x64.msu' else: # Some future OS? return None
Message was sent while issue was closed.
On 2016/01/19 18:19:54, brucedawson wrote: > > I think this broke part of "gclient runhooks". The > > get_toolchain_if_necessary.py module imports "_winreg" which exists under > > vs2013_files but not anywhere else. > > > > Not sure why I'm the only one seeing it, perhaps because I'm a last hold-out > for > > CygWin. > > > > I've removed the "import _winreg" line and "runhooks" seems to work but it's > > impossible to know if other things are broken. > > I would assume that CygWin is the difference. I'm not sure where in vs2013_files > _winreg is - can you explain? > > I had a different version of GetInstallerName() that used reg.exe instead of > _winreg. Can you try pasting this in to see if it works? It's a bit inelegant > using a subprocess to read a registry key, but it does work. > > def GetInstallerName(): > """Return the name of the Windows 10 Universal C Runtime installer for the > current platform, or None if installer is not needed or not applicable. > The registry has to be used instead of sys.getwindowsversion() because > Python 2.7 is only manifested as being compatible up to Windows 8, so the > version APIs helpfully return a maximum of 6.2 (Windows 8). > """ > ver_re = re.compile('.*REG_SZ * (\d+)\.(\d+)') > key_name = '"HKLM\Software\Microsoft\Windows NT\CurrentVersion"' > output = subprocess.check_output('reg query %s /v CurrentVersion' % key_name) > match = ver_re.match(output.replace('\n', ' ')) > if match.groups() == ('6', '1'): > # Windows 7 and Windows Server 2008 R2 > return 'Windows6.1-KB2999226-x64.msu' > elif match.groups() == ('6', '2'): > # Windows 8 and Windows Server 2012 > return 'Windows8-RT-KB2999226-x64.msu' > elif match.groups() == ('6', '3'): > # Windows 8.1 and Windows Server 2012 R2, or Windows 10 > return 'Windows8.1-KB2999226-x64.msu' > else: > # Some future OS? > return None We shouldn't change back to reg.exe for that. gyp_chromium does this: https://code.google.com/p/chromium/codesearch#chromium/src/build/gyp_chromium... If you insist on running cygwin python, something like that should be added to gclient.py.
Message was sent while issue was closed.
> We shouldn't change back to reg.exe for that. gyp_chromium does this: > https://code.google.com/p/chromium/codesearch#chromium/src/build/gyp_chromium... > > If you insist on running cygwin python, something like that should be added to > gclient.py. bcwhite@ - can you put together a patch to get this working on cygwin?
Message was sent while issue was closed.
> I think this broke part of "gclient runhooks". The > get_toolchain_if_necessary.py module imports "_winreg" which exists under > vs2013_files but not anywhere else. To clarify - vs2013_files contains winreg.h. However this is unrelated to Python's _winreg module - red herring. |