Some build machines end up running vctip.exe for some reason and then
it doesn't shut down in a timely manner, leaving locks on directories.
This changes the packaging script so that vctip.exe is not packaged, and
therefore won't be run.
vctip.exe is the "Microsoft VC compiler and tools experience
improvement data uploader" and it presumably runs automatically as part
of running the compiler. It's not clear what triggers it to run,
however omitting it should be safe.
BUG=735226
Change-Id: Ie6af562def6214a5bb130ccc09c732efc1769bcd
Reviewed-on: https://chromium-review.googlesource.com/544395
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
The second preview of VS 2017 Update 3 removed the MFC DLLs from the
redist directory. Luckily it appears that we don't actually need them.
The directories were also renamed from VC150 to VC141. This change
switches to VC* to make it more robust, enabled by the use of glob added
a few changes ago.
crrev.com/2938453003, which tests a package that was created with this
updated script, passed.
BUG=683729
R=scottmg@chromium.org
Change-Id: I4ae5dec949d16a83e1751e3d2ff7bd10a78b680f
Reviewed-on: https://chromium-review.googlesource.com/534353
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
On recent SDKs the size of the toolchain package grew. This change
filters out some unneeded directories in order to minimize this growth.
This change also fixes the bin paths for the 10.0.15063.0 SDK. Starting
with this SDK version the SDK version is part of the path. The script
does *not* handle packaging older SDKs anymore - older versions of the
script can be used for that purpose.
The 10.0.15063.0 SDK will be needed eventually in order to support
Windows 10 Creators Update.
Test builds are running on crrev.com/2913873003 (VS 2017) and
crrev.com/2914643003 (VS 2015).
Bug: 683729,682416
Change-Id: Ia89e3253869a45dd10c923a2edee53aaf086e12c
Reviewed-on: https://chromium-review.googlesource.com/519982
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
VS 2017 Preview installs to a different directory from VS 2017 RTM, so
the packaging script needs to be updated to handle this. It does this by
using vswhere.exe so that any VS 2017 install can be found
automatically. If there are multiple installs then it is not well
defined which one will be found, so make sure you don't have multiple
installs.
The other change is to more robustly find the many directory paths which
contain embedded version numbers. Previously these were hard-coded for
VS 2017 RTM but this quickly gets tedious so now glob.glob is used to
find the matching directories. This will intentionally fail if there is
any ambiguity.
R=scottmg@chromium.org
BUG=683729
Change-Id: I02f7ae7589e271d6d9897f899e0730d7163f76ef
Reviewed-on: https://chromium-review.googlesource.com/516442
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Scott Graham <scottmg@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>
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
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
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
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
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
Bruce Dawson
thakis@chromium.org
sebmarchand@chromium.org
scottmg@chromium.org
scottmg@chromium.org