Change crrev.com/1825163003 attempted to enable crash dump collection
on build machines, and it worked fine on local testing. However it only
worked because local testing was done using 64-bit Python. The builders
use python from depot_tools which is 32-bit Python so the changes all
went to "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft" instead of
to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft", which means they were
ignored. For a year. This made investigation of linker crashes more
complicated than needed.
This change uses the necessary winreg.KEY_WOW64_64KEY dance so that the
64-bit registry is always used, whether running 32-bit Python or 64-bit
Python. Both versions were tested locally. The behavior on 32-bit
Windows is unknown but we don't support building on 32-bit Windows
anyway, and any failures would be rendered harmless by the try/except
block.
R=scottmg@chromium.org
BUG=704286
Change-Id: I6abc0e1e9c69b9a4e4b9c705bea9e4faadd0945c
Reviewed-on: https://chromium-review.googlesource.com/473567
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
The versions of dbghelp.dll that ship with the latest 10.0.14393.0 SDK
(yes, there are multiple versions) as of the VS 2017 launch cannot
handle /debug:fastlink binaries created by VS 2017. This leads to hangs
during symbol lookup, as reported here:
https://developercommunity.visualstudio.com/content/problem/36255/chromes-base-unittests-fails-with-vs-2017-due-to-s.html
The recommended fix is to copy dbghelp.dll from the VS install instead,
from Common7\IDE\CommonExtensions\Microsoft\TestWindow\Extensions\CppUnitFramework
Without this fix base_unittests will hang and windbg will not work on
/debug:fastlink binaries. With this fix base_unittests completes
promptly.
BUG=683729
Change-Id: Ie58b9d898a1feb04f11e99891035d2e40a2a9c0f
Reviewed-on: https://chromium-review.googlesource.com/461385
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
VS 2017 has been released and needs to be packaged so that we can
experiment with building with it. This is an initial pass at updating
the packaging script. The file layout has changed significantly in VS
2017. Compatibility with VS 2013 and VS 2015 has, I believe, been
maintained but it is not important enough to merit significant testing.
BUG=683729
Change-Id: I68e5a8d9fd389132b641743dbc070108497f54cb
Reviewed-on: https://chromium-review.googlesource.com/457153
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
The get-toolchain script still contained leftover goop for installing
the UCRT, even though that misguided plan was abandoned last year. This
change deletes that.
The get-toolchain script also confusingly used the vs2013_files
directory for anything that wasn't VS 2015. It doesn't technically make
any difference now that we use hashes for the toolchain directories, but
it was confusing when experimenting with VS 2017.
R=sebmarchand@chromium.org
BUG=683729
Change-Id: Ie0d3eccffe4796d4c5e23a28276acdd757e290d4
Reviewed-on: https://chromium-review.googlesource.com/453122
Reviewed-by: Sébastien Marchand <sebmarchand@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
svn://svn.chromium.org/chrome-internal/trunk/src-internal/ doesn't seem
to exist any more.
d:\src>"d:\src\depot_tools\svn_bin\svn.exe" ls --non-interactive svn://svn.chromium.org/chrome-internal/trunk/src-internal/
svn: Can't connect to host 'svn.chromium.org': A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
R=brucedawson@chromium.org
Review-Url: https://codereview.chromium.org/2327213002
The message now look like this:
2 files missing from the 9ff97version of the toolchain:
vs2013_files\9ff97\win_sdk\Include\10.0.10240.0\ucrt\assert.h
vs2013_files\9ff97\win_sdk\Include\10.0.10240.0\ucrt\complex.h
22 extra files in the 9ff97version of the toolchain:
vs2013_files\9ff97\win_sdk\Include\10.0.10240.0\ucrt\assert_.h
vs2013_files\9ff97\win_sdk\Include\10.0.10240.0\ucrt\complex_.h
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\string\wmemmove_s.cpp
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\time\asctime.cpp
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\time\clock.cpp
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\time\ctime.cpp
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\time\days.cpp
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\time\difftime.cpp
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\time\ftime.cpp
vs2013_files\9ff97\win_sdk\Source\10.0.10240.0\ucrt\time\gmtime.cpp
...
R=thakis@chromium.org
Review-Url: https://codereview.chromium.org/2092753003
Filenames must have their case preserved so the files can be opened,
but they need to be lowercased when hashed and sorted, to match the
expected hash.
In other words, this patch moves the lower-casing from GetFileList
(except to sort the list) to where filenames are fed into the hash.
BUG=495204
Review-Url: https://codereview.chromium.org/2039563002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@300696 0039d316-1c4b-4281-b951-d872f2087c98
I often ends up with a corrupt toolchain because I've used Windbg and there's now a bunch of PDB files in win_sdk/Debuggers/sym/... , I think that it's safe to ignore these files (the original package doesn't contain any of these files).
It's also useful to have more details about which files are missing and or which ones shouldn't be here when we get an invalid toolchain hash.
Finally, if you the hash of a toolchain doesn't correspond to the name of its root directory then it should be removed.
Review-Url: https://codereview.chromium.org/1974453003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@300557 0039d316-1c4b-4281-b951-d872f2087c98
This change adds a --override option to the VC++ packaging script so
that an arbitrary bin/include/lib containing directory can be used to
package up those components of VC++. See this post for details:
https://blogs.msdn.microsoft.com/vcblog/2016/02/16/try-out-the-latest-c-compiler-toolset-without-waiting-for-the-next-update-of-visual-studio/
Typical usage is like this:
package_from_installed.py 2015 --override <projdir>\packages\VisualCppTools.14.0.24109-Pre\lib\native
In order to make this work the path tuple support was fixed so that the
local relative path was propagated to the destination path, instead of
just the file name.
At the same time, the code to package up the UCRT installers was deleted
because it isn't needed, and windows.winmd is filtered out because it
makes consistent package creation impossible (it is different on every
machine).
While removing the UCRT installers I discovered nested if VS_VERSION
checks. Oops. Fixed.
BUG=440500
Review-Url: https://codereview.chromium.org/1967653002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@300527 0039d316-1c4b-4281-b951-d872f2087c98
Toolchain crashes on build machines are an ongoing problem, particularly
with the VC++ 2015 migration. Setting this registry key tells Windows
Error Reporting to record minidumps (a few MB typically) to a local
directory, up to a maximum of ten. This should help with investigations.
This change also suppresses Windows Error Reporting dialogs with the
DontShowUI registry value, to avoid builder hangs on crashes.
See also crrev.com/1816333002
BUG=440500
Review URL: https://codereview.chromium.org/1825163003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@299426 0039d316-1c4b-4281-b951-d872f2087c98
Every time I write a json file, I end up wishing I put my toplevel items
into non-toplevel items down the line when I want to add more stuff to the
json file. Address this now, while no toolchain with this json file has
been built yet.
Follow-up to https://codereview.chromium.org/1706423002/
BUG=495204
Review URL: https://codereview.chromium.org/1718083003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298908 0039d316-1c4b-4281-b951-d872f2087c98
No intended behavior change. This makes it possible to dump this state into
SetEnv.x32.json and SetEnv.x64.json in an easy follow-up.
BUG=495204
Review URL: https://codereview.chromium.org/1708223002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298856 0039d316-1c4b-4281-b951-d872f2087c98
The UCRT is now optional and it failed to install on one builder.
Making optional to fix build break
If this doesn't fix the break on the waterfall then the switch
to VS 2015 will need to be reverted (crrev.com/1598493004).
TBR=scottmg@chromium.org
BUG=440500
Review URL: https://codereview.chromium.org/1680433002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298634 0039d316-1c4b-4281-b951-d872f2087c98
Right now I get
Calculating hash of toolchain in vs2013_files. Please wait...
Calculating hash of toolchain in vs2013_files. Please wait...
Calculating hash of toolchain in vs2013_files. Please wait...
Calculating hash of toolchain in vs2013_files. Please wait...
Calculating hash of toolchain in vs2013_files. Please wait...
Calculating hash of toolchain in vs2013_files. Please wait...
which isn't very informative (or at least a bit confusing as to why it's
doing the same thing 6 times).
R=brucedawson@chromium.org
Review URL: https://codereview.chromium.org/1671433002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298593 0039d316-1c4b-4281-b951-d872f2087c98
This change packages the api-ms-* DLLs and the VS 2015 CRT DLLs in all
of the VS package directories that we add to the path, so that they can
run without having the UCRT installed.
The Common7\IDE path was removed because it isn't actually packaged, in
VS 2013 or VS 2015, so adding it to the path is purely confusing.
In addition to changing the packaging script the installation script has
to change in order to continue if the UCRT cannot be installed. It
still makes sense to try to install it, and print a message saying where
the installer is, for the convenience of Google developers who may want
more flexibility in running VS 2015 binaries.
A 'calculating hash' message was added to make the mysterious hashing
hangs (which can be several minutes long) less mysterious.
BUG=440500
Review URL: https://codereview.chromium.org/1660723002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298541 0039d316-1c4b-4281-b951-d872f2087c98
In change crrev.com/1504983002 the include\ucrt path from
the Windows 10 SDK was added to the include search path,
but this is not a legal thing to do on VS 2013. This change
makes the ucrt path VS 2015 specific.
Testing shows that this makes no difference to the VS 2015
package.
BUG=440500
Review URL: https://codereview.chromium.org/1609933004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298330 0039d316-1c4b-4281-b951-d872f2087c98
We use depot_tools's toolchain to build LLVM on the clang/win bots.
llvm-symbolizer relies on VSINSTALLDIR to be set to find the DIA SDK,
so set it. While here, also set VCINSTALLDIR.
BUG=82385
Review URL: https://codereview.chromium.org/1604423002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298326 0039d316-1c4b-4281-b951-d872f2087c98
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
Review URL: https://codereview.chromium.org/1588673004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298286 0039d316-1c4b-4281-b951-d872f2087c98
I coded these incorrectly in a previous change and hit them when
building a VS package.
Review URL: https://codereview.chromium.org/1567863004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298156 0039d316-1c4b-4281-b951-d872f2087c98
This change updates the packaging script for VS 2015 Update 1. Changes
include:
- Filtering out Windows Performance Toolkit to save space
- Filtering out .msi files to save space
- Adding a 'dryrun' option to quickly print statistics
- Allowing specifying what OS sub-version is desired
- Filtering out unused versions from the include/lib/source directories
- Avoiding the double-include of the ucrt directory
- Adding ucrt directory to include and lib path
- Handling running from 64-bit or 32-bit python
R=scottmg@chromium.org
BUG=chromium:440500
Review URL: https://codereview.chromium.org/1504983002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297894 0039d316-1c4b-4281-b951-d872f2087c98
1. GetFileList() returns a list of path\names on Windows but of path/names on
non-Windows. To not perturb existing hashes, I guess the hashing code should do
path.replace('/', '\\') before hashing.
2. GetFileList() returns a sorted list of filenames, and \ compares pretty
different than / (the former is less than all numbers while the latter
is greater, for example). So replace / with \\ for sorting too.
With this change, OS X produces the same file hash as Windows.
The script still early-exits on non-Windows, so no visible change yet.
BUG=495204
Review URL: https://codereview.chromium.org/1287543005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@296271 0039d316-1c4b-4281-b951-d872f2087c98
It still early-exits on non-Windows, so no visible change yet.
BUG=495204
Review URL: https://codereview.chromium.org/1181943003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295807 0039d316-1c4b-4281-b951-d872f2087c98
Hashes for both the 2013 and 2015 toolchain don't change for me locally with
this change, looks like there are no hidden or system files in the toolchain.
(I tried with the "you are a googler" flow.)
No intended behavior change.
BUG=495204
Review URL: https://codereview.chromium.org/1200113004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295804 0039d316-1c4b-4281-b951-d872f2087c98
Based on some fiddling on a local VM (see bug), but possibly still insufficient.
TBR=sebmarchand@chromium.org
BUG=492774, 495944
Review URL: https://codereview.chromium.org/1160683005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295521 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
Breaking chromium waterfall.
Original issue's description:
> win: Fix current toolchain path with old packaging
>
> I broke boringssl's use of depot_tools toolchain as I changed the
> name of the sdk path key. This happened to work in Chrome because
> src/ has fallback behaviour.
>
> Restore the 'win8sdk' name when unpacking a current/old-style
> toolchain package (i.e. what everyone is still using).
>
> TBR=dpranke@chromium.org
> R=davidben@chromium.org
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=295492
TBR=davidben@chromium.org,dpranke@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1167753003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295493 0039d316-1c4b-4281-b951-d872f2087c98
I broke boringssl's use of depot_tools toolchain as I changed the
name of the sdk path key. This happened to work in Chrome because
src/ has fallback behaviour.
Restore the 'win8sdk' name when unpacking a current/old-style
toolchain package (i.e. what everyone is still using).
TBR=dpranke@chromium.orgR=davidben@chromium.org
Review URL: https://codereview.chromium.org/1159433006
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295492 0039d316-1c4b-4281-b951-d872f2087c98
This is the other side of https://codereview.chromium.org/1163723003/
The changes here are to remove the use of 'vs2013_files' and 'win8sdk'
(as those will be different numbers soon enough) but still maintain
behaviour for the old "style" while in transition.
Secondarily, to remove the dependence of these two scripts on
'toolchain2013.py' as most of the script is now unused.
R=dpranke@chromium.org
BUG=440500, 492774
Review URL: https://codereview.chromium.org/1165563003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295485 0039d316-1c4b-4281-b951-d872f2087c98
I started to build a package for setting up a VS2015 bot, and realized
I didn't really remember how the toolchain setup worked. So I wrote
a readme for this directory.
I see I will live to regret putting way too many "2013"s in various
places in these scripts. :/
R=dpranke@chromium.org
BUG=492774
Review URL: https://codereview.chromium.org/1150033010
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@295437 0039d316-1c4b-4281-b951-d872f2087c98
5498b95831 runs gsutil using 'os.execv',
which, on Windows, apparently causes it to return before completion.
Also add verbosity to '7z' failures on toolchain downloading.
BUG=chromium:445425
TEST=bot
- Ran on bot, this fix solves the problem that we were seeing.
R=pgervais@chromium.org, sergeyberezin@chromium.org
Review URL: https://codereview.chromium.org/828463003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293507 0039d316-1c4b-4281-b951-d872f2087c98
This could be simplified a bunch more, but this path was already
non-functional and tries to download Express which is a waste of
time and confusing for people.
R=dpranke@chromium.org
BUG=433551
Review URL: https://codereview.chromium.org/775733002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@293199 0039d316-1c4b-4281-b951-d872f2087c98
Sorry, I screwed up. This breaks Express-only per skia:2781. I'll reland it before I push the next VS update.
> Add winrt to the INCLUDE directories of the toolchain bundler.
>
> The motivation is that vcvarsall sets it, and that it might make it possible to
> land https://codereview.chromium.org/405723002/ one day.
>
> BUG=395405
> TBR=jochen
>
> Review URL: https://codereview.chromium.org/393233004TBR=thakis@chromium.org
Review URL: https://codereview.chromium.org/424813003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@285924 0039d316-1c4b-4281-b951-d872f2087c98
This allows Googlers who didn't pass existing checks to use G storage and
the Pro version of Visual studio.
BUG=
TBR=maruel
Review URL: https://codereview.chromium.org/382373002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@283250 0039d316-1c4b-4281-b951-d872f2087c98
Bruce Dawson
scottmg
sebmarchand
hans@chromium.org
thakis@chromium.org
bcwhite@chromium.org
djacques@chromium.org
scottmg@chromium.org
thakis@chromium.org
liamjm@chromium.org