Ran "2to3 -w -n -f print ./" and manually added imports.
Ran "^\s*print " and "\s+print " to find batch/shell scripts, comments and the like with embedded code, and updated them manually.
Also manually added imports to files, which used print as a function, but were missing the import.
The scripts still work with Python 2.
There are no intended behaviour changes.
Bug: 942522
Change-Id: Id777e4d4df4adcdfdab1b18bde89f235ef491b9f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1595684
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Auto-Submit: Raul Tambre <raul@tambre.ee>
And indent properly as well.
Change-Id: I78e1f67d7820120bf809f1ac3ab64ce48c74e804
Reviewed-on: https://chromium-review.googlesource.com/c/1458784
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
The Windows toolchain should be downloaded during gclient runhooks,
however because get_toolchain_if_necessary.py can either configure an
existing toolchain or download a toolchain there have been problems when
the toolchain is downloaded at an unexpected point. In particular, a
toolchain download during gn gen can lead to parallel downloads and
configuration failures.
The --nodownload option will be passed (after a subsequent change) by
build\vs_toolchain.py. A --nodownload option is needed instead of a more
positive --allowdownload option because of backwards compatibility. This
change will have no effect until the build\vs_toolchain.py change is
landed.
Bug: 584393, 662325
Change-Id: I9a0950e066744c0310e49e45d001a9113f1831cf
Reviewed-on: https://chromium-review.googlesource.com/c/1439805
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
When non-Googlers try to build Chromium for the first time they get an
error saying:
Please follow the instructions at https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md
However those instructions are quite long and it's not obvious to some
users which part of the instructions they have forgotten. The most
likely is that they didn't set DEPOT_TOOLS_WIN_TOOLCHAIN=0, so this
changes the error message to suggest that directly.
Auto-detecting the correct state for DEPOT_TOOLS_WIN_TOOLCHAIN was
tried in crrev.com/c/1374833 but deemed impractical.
Bug: 907300, angleproject:2712
Change-Id: I45a9f59babe90bbe2137d49c555884d7bbbcf170
Reviewed-on: https://chromium-review.googlesource.com/c/1382942
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
These changes ensure that the packaged Windows SDK bits support targeting
ARM64 Windows. This change must not land until crrev.com/c/1339101 lands,
since it is needed to the varying number of vs_runtime_dll_dirs.
Bug: 893460
Change-Id: Ie32563067c6fb6078acfaccd6d3d572d1dd44888
Reviewed-on: https://chromium-review.googlesource.com/c/1330185
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Renames DEPOT_TOOLS_WIN_TOOLCHAIN_HTTP_BASE_URL to
DEPOT_TOOLS_WIN_TOOLCHAIN_BASE_LOCATION. This environment variable can
now point to a local directory where the Windows SDK zip file is stored.
This allows non-Googlers to cross-compile Chromium for Windows.
Bug: 852347
Change-Id: I00650e84247f35b4b8cfba204e0f2afd0882b69b
Reviewed-on: https://chromium-review.googlesource.com/1098256
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Add support for downloading Windows VS toolchain from a HTTP URL.
This is useful for developers that do not have access to the
Chrome toolchain.
If the developer specifies DEPOT_TOOLS_WIN_TOOLCHAIN_HTTP_BASE_URL
environment variable, the toolchain will be downloaded from that
url.
Bug: 830569
Change-Id: I41d815a4460085c3b028f56f2e01adc68d8410fe
Reviewed-on: https://chromium-review.googlesource.com/1002892
Commit-Queue: Kimmo Kinnunen FI <kkinnunen@nvidia.com>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Git Credential Manager for Windows (as of git 2.14.1) really wants to
pop up a modal dialog. Setting this environment variable avoids this
so that the check for src-internal access can quietly fail.
Ref: https://github.com/Microsoft/Git-Credential-Manager-for-Windows/issues/482
Bug: 755694
Change-Id: I38aec008662fa0a6bccb0a6220d376063ee790e7
Reviewed-on: https://chromium-review.googlesource.com/617502
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Currently, the Windows toolchain is installed in a subdirectory under
"depot_tools". Allow this installation destination to be overridden,
either by flag (useful for testing) or via environment variable (to be
used in Chromium recipe).
BUG=chromium:727917
TEST=local
- Ran explicitly w/ flag, seems to work.
- Ran via Chromium's "vs_toolchain" with and without environment
variable override, seems to install correctly.
Change-Id: I6b33832d7f099796e23da0548949073c70a17788
Reviewed-on: https://chromium-review.googlesource.com/521663
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Robbie Iannucci <iannucci@chromium.org>
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 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
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
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
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
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
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
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
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
get_toolchain_if_necessary.py contains a number of Windows-isms, including
computing hashes on Windows-style path names, so does not work under
Cygwin. This change reruns it under depot_tools' Windows Python if run
from Cygwin Python.
Review URL: https://codereview.chromium.org/233563003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@263301 0039d316-1c4b-4281-b951-d872f2087c98
- Don't try to wrap download_from_google_storage --config, instead just
request that the user runs it manually. (This is annoying either way
but making it magically run makes it less clear what's going on, and so
harder to debug when something goes wrong, per linked bug).
- Check that SHA1s are passed as expected on the command line in case
the script is run directly, rather than from gyp_chromium.
R=scherkus@chromium.org
BUG=349596
Review URL: https://codereview.chromium.org/189093017
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@256049 0039d316-1c4b-4281-b951-d872f2087c98
The gs:// download path is much faster. Move anyone who could have
access to gs://chrome-wintoolchain/ over to that for less pain.
The downside is that we have to prompt them to run
download_from_google_storage --config which people are going to
complain about, but I think this is a better experience overall.
R=iannucci@chromium.org,hinoka@chromium.org
BUG=349964
Review URL: https://codereview.chromium.org/191373002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@255696 0039d316-1c4b-4281-b951-d872f2087c98
I tried a git-ish tree/blob model, but way too slow for a ton of files.
This maps easily on to the current way the tree is mapped, saves
temp space on bots (because the full isos aren't downloaded), and is
a lot faster too. It means we can pull old revisions too now.
TBR=iannucci@chromium.org
BUG=348350
Review URL: https://codereview.chromium.org/185423004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@254421 0039d316-1c4b-4281-b951-d872f2087c98
git sometimes blocks asking for a password. On a random machine that
didn't know anything about google/chromium, it failed immediately with
"fatal: could not read Username for 'https://chrome-internal.googlesource.com': No such file or directory"
but on my real machine w/o _netrc it blocks and wants this:
Username for 'https://chrome-internal.googlesource.com':
Password for 'https://chrome-internal.googlesource.com':
There's no --non-interactive unfortunately, it's supposed to magically
decide if it's connected to a tty and behave appropriately. It does
not, perhaps because of being wrapped in depot_tools .bat files,
perhaps an msysgit-port bug, perhaps being called from python. Anyway
https://github.com/bower/bower/issues/1009 had a magic incantation
that works for this case: 'true' is available in the msys
distribution.
R=iannucci@chromium.org
BUG=323300
Review URL: https://codereview.chromium.org/182553004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@253844 0039d316-1c4b-4281-b951-d872f2087c98
If user is unauthenticated, svn ls would just hang waiting at
"Password for 'User':", now it'll correctly fail with
"svn: Can't get password".
R=iannucci@chromium.org
BUG=323300,346472
Review URL: https://codereview.chromium.org/178763003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@253004 0039d316-1c4b-4281-b951-d872f2087c98
Moves the update functionality out of update_depot_tools into src/ in https://codereview.chromium.org/175573004 .
get_toolchain_if_required.py now expects a list of hashes on the
command line, and makes sure that it gets one of those.
toolchain2013.py saves a .json which contains information relevant to the
interests of the caller, so that it can set up the parent environment. This
is returned via the --output-json command line argument to get_...py
R=iannucci@chromium.org
BUG=323300
Review URL: https://codereview.chromium.org/168603004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@252725 0039d316-1c4b-4281-b951-d872f2087c98
It's somewhat annoying to have the script delete your toolchain
directory (at least during testing) and it necessitates downloading
3-4G to restore, so add a short timeout before doing so.
Also, hide the output of taskkill'ing mspdbsrv so that the first message
isn't '''ERROR: The process "..." not found.'''.
R=maruel@chromium.org
BUG=323300
Review URL: https://codereview.chromium.org/146583012
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@251084 0039d316-1c4b-4281-b951-d872f2087c98
And for now, defaults to Express.
Main changes:
- Valid hash becomes a set of hashes one for Pro, one for Express
- Include WDK to get an old copy of ATL as that doesn't come
with Express
BUG=323300
R=maruel@chromium.org
Review URL: https://codereview.chromium.org/148453008
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@248622 0039d316-1c4b-4281-b951-d872f2087c98
Raul Tambre
Tom Anderson
Lei Zhang
Bruce Dawson
Henrique Ferreiro
Kimmo Kinnunen
Scott Graham
Dan Jacques
sebmarchand
hans@chromium.org
bcwhite@chromium.org
thakis@chromium.org
liamjm@chromium.org
wittman@chromium.org
scottmg@chromium.org