Make landmines work on the first landmine.

Make landmines work on the first landmine.

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

Committed: https://code.google.com/p/v8/source/detail?r=22557

[Michael Achenbach, 2014-07-23 11:03:03]

PTAL

[Jakob Kummerow, 2014-07-23 11:05:48]

lgtm

https://codereview.chromium.org/410893002/diff/1/build/landmines.py
File build/landmines.py (right):

https://codereview.chromium.org/410893002/diff/1/build/landmines.py#newcode75
build/landmines.py:75: print "Setting landmine: %s" % triggered
are you keeping these print statements intentionally?

[Michael Achenbach, 2014-07-23 11:21:50]

On 2014/07/23 11:05:48, Jakob wrote:
> lgtm
> 
> https://codereview.chromium.org/410893002/diff/1/build/landmines.py
> File build/landmines.py (right):
> 
> https://codereview.chromium.org/410893002/diff/1/build/landmines.py#newcode75
> build/landmines.py:75: print "Setting landmine: %s" % triggered
> are you keeping these print statements intentionally?

Yes - see the last sentence in the CL description. There is another landmine
problem left (http://crbug.com/396084) which I hope to better debug when it
happens.

[Michael Achenbach, 2014-07-23 11:33:38]

Committed patchset #1 manually as r22557 (presubmit successful).