Xcode uses a different naming scheme for directories within
the xcodebuild directory. But it is safe to just delete
everything withing xcodebuild or out. Keep the soft clobber
for windows' build directory only, where subdirectories
follow the *release* and *debug* naming scheme.
BUG=chromium:403263
LOG=n
TBR=jochen@chromium.org
Review URL: https://codereview.chromium.org/955953002
Cr-Commit-Position: refs/heads/master@{#26852}
Without this change, it is non-trivial to know during
runhooks, if a landmine was just triggered in a checkout
that doesn't have the initial landmines script CL yet, i.e.
that didn't create a .landmines file yet.
BUG=chromium:403263
LOG=n
Review URL: https://codereview.chromium.org/954153002
Cr-Commit-Position: refs/heads/master@{#26842}
This runs the landmines script as a gclient hook. It can
as such be used to clobber local checkouts when hooks are
run locally.
It is a softer version than chromium's landmines script, as
it only deletes directories in the output directory due
to compatibility with MSVS which has "build" hardcoded as
output directory in several places.
BUG=chromium:403263
LOG=n
Review URL: https://codereview.chromium.org/955463002
Cr-Commit-Position: refs/heads/master@{#26831}
Currently, some builders are in a clobber-landmine loop.
Clobber deletes the .landmines tracker (sigh). Difficult to
know if we are right after a clobber or if it is first-time
landmines deployment. Also, a landmine-triggered clobber
right after a clobber is not possible. Different clobber
methods for msvs, xcode and make all have different
blacklists of files that are not deleted.
After the branch point, all v8 branch builders have to be
manually clobbered, because the appearance of the
landmines.py script and the first landmine request are in
the same branch CL.
TBR=jochen@chromium.org
Review URL: https://codereview.chromium.org/457063002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23012 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
With the original script, landmines don't work if the initial commit of the landmine script and the first landmine are in the same build. In this case, the landmine file wouldn't exist yet and no landmine would be triggered. But the updated landmine content would have still been written, omitting the landmine.
Now, the script will initialize an empty landmine file if none exists. This will make sure that a landmine is set on the branch builders after the next branch point.
This also adds some debugging output to better trace when landmines are set/deleted.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/410893002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22557 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
