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
This allows "git cl try" to just work for projects without any PRESUBMIT
but with cq.cfg in default location (infra/config/cq.cfg). This also
ships all presubmit bots, since these usually fail LGTM checks anyway.
BUG=522909
Review URL: https://codereview.chromium.org/1579423004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298251 0039d316-1c4b-4281-b951-d872f2087c98
Now that we're using real override/final and not also using
virtual on the same methods, this transitional blacklist
can go away.
R=agable, dcheng
Review URL: https://codereview.chromium.org/1564403003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298201 0039d316-1c4b-4281-b951-d872f2087c98
Through a comedy of wrapper scripts, the ^ is being swallowed, which
causes the `git config` invocation to match all lines which HAVE
"remote" in them, instead of matching lines which BEGIN with remote.
R=maruel@chromium.org, pkasting@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1566343002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298185 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
If the stderr buffer used in git diff became full
before stdout was completely consumed, git cl upload
would deadlock.
This also sets GIT_PAGER to be perfectly sure no pager
is triggered by the git commands run. I haven't
seen that as a problem but it's a reasonable (and
common) precaution.
BUG=558726
Review URL: https://codereview.chromium.org/1544813002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@298090 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
If you specify a directory incorrectly to roll_dep then it may not be
obvious why it cannot be found. For instance, "roll-dep tools\gyp" vs.
"roll-dep src\tools\gyp". This change prints the full directory.
This change also clarifies what is meant by a clean tree to make that
error message easier to understand.
R=maruel@chromium.org
Review URL: https://codereview.chromium.org/1507623003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297875 0039d316-1c4b-4281-b951-d872f2087c98
This is a good prototypical example of how to do it :-).
TBR for OWNERS change for recipes.cfg.
BUG=564920
R=iannucci@chromium.org,martiniss@chromium.org
TBR=phajdan.jr@chromium.org
Review URL: https://codereview.chromium.org/1494103004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297851 0039d316-1c4b-4281-b951-d872f2087c98
This changes the 'empty' branch detection to compare the commit trees instead
of the commit hashes. This avoids empty-branch detection when you have multiple
renames on the branch that end up canceling eachother out. Previously you'd
end up with the rename-commits, in order, in your rebased branch, even though
when you run `git upstream-diff` you get nothing.
R=agable@chromium.org, jochen@chromium.org, vadimsh@chromium.org
BUG=438208
Review URL: https://codereview.chromium.org/1497313002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297849 0039d316-1c4b-4281-b951-d872f2087c98
We are making depot_tools a proper (chromium) recipe package, which assumes
that recipes are located in recipes/. So I need to move these other kinds of
recipes out of the way.
BUG=564920
R=dpranke@chromium.org, iannucci@chromium.org
Review URL: https://codereview.chromium.org/1494793002 .
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297837 0039d316-1c4b-4281-b951-d872f2087c98
Fix a bug that left branches tracking a dead branch if both their parent
and grand-parent were left with no changes after a "rebase-update" step.
Given the following initial state:
$ git map-branches -v
origin/master
a
b
c * [ ahead 1 ]
without this patch, a "git rebase-update" on this tree state would
leave the branch "c" as tracking a non-existing branch "a":
$ git recursive-rebase
a up-to-date
b up-to-date
c up-to-date
Reparented c to track a (was tracking b)
Deleted branch b (was 448d1da).
Deleted branch a (was 448d1da).
$ git map-branches -v
{a:GONE}
c *
with the patch, we record that the branch "c" is tracking must be
updated twice and we end up in a state were "c" is correctly tracking
"origin/master":
$ git recursive-rebase
a up-to-date
b up-to-date
c up-to-date
Reparented c to track origin/master (was tracking b)
Deleted branch b (was 448d1da).
Deleted branch a (was 448d1da).
$ git map-branches -v
origin/master
c * [ ahead 1 ]
BUG=456806
Review URL: https://codereview.chromium.org/1482753002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297792 0039d316-1c4b-4281-b951-d872f2087c98
Manually generating param strings shows that the 1/2 values do not work.
Review URL: https://codereview.chromium.org/1482153002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@297732 0039d316-1c4b-4281-b951-d872f2087c98
brucedawson@chromium.org
tandrii@chromium.org
machenbach@chromium.org
bauerb@chromium.org
recipe-roller@chromium.org
danakj@chromium.org
iannucci@chromium.org
bratell@opera.com
sergiyb@chromium.org
akuegel@chromium.org
erikcorry@chromium.org
luqui@chromium.org
sdefresne@chromium.org
nednguyen@google.com
cbentzel@chromium.org