i#1565: use random number on git log failure

Commit log for first patchset:
---------------
i#1565: use random number on git log failure

We use a random number instead of fatal error on git log failure.
---------------

[bruening, 2016-04-04 16:20:46]

https://codereview.appspot.com/294130043/diff/1/CMakeLists.txt
File CMakeLists.txt (right):

https://codereview.appspot.com/294130043/diff/1/CMakeLists.txt#newcode479
CMakeLists.txt:479: set(git_out 1459748879)
As discussed offline, this is a real value that is going to be misleading versus
actual date values: better to pick a number that will not be confused with any
real numbers to make it clear it's artificial and has no meaning.

[zhaoqin, 2016-04-04 16:23:04]

Commit log for latest patchset:
---------------
i#1565: use random number on git log failure

We use a random number instead of fatal error on git log failure.

Review-URL: https://codereview.appspot.com/294130043
---------------

[bruening, 2016-04-04 16:29:03]

https://codereview.appspot.com/294130043/diff/20001/CMakeLists.txt
File CMakeLists.txt (right):

https://codereview.appspot.com/294130043/diff/20001/CMakeLists.txt#newcode478
CMakeLists.txt:478: # use random number instead
Please explain how it was chosen: i.e., that the resulting date is a sentinel
value was can identify as artificial.

https://codereview.appspot.com/294130043/diff/20001/CMakeLists.txt#newcode479
CMakeLists.txt:479: set(git_out 1559748879)
This is only 5 years out: I would suggest further.  Also, why not a nicer final
# that's easy to see as unique?  How about a final # of 33333, either by setting
2879971200 here (maybe in a math expr so it's clear) or delay-set directly
below.

[zhaoqin, 2016-04-04 16:45:17]

Commit log for latest patchset:
---------------
i#1565: use a future date for VERSION_NUMBER_PATCHLEVEL on git log failure

We use a future date for VERSION_NUMBER_PATCHLEVEL instead of fatal
error on git log failure.

Review-URL: https://codereview.appspot.com/294130043
---------------

[zhaoqin, 2016-04-04 16:49:56]

Commit log for latest patchset:
---------------
i#1565: use a future date for VERSION_NUMBER_PATCHLEVEL on git log failure

We use a future date for VERSION_NUMBER_PATCHLEVEL instead of fatal
error on git log failure.

Review-URL: https://codereview.appspot.com/294130043
---------------

[bruening, 2016-04-04 16:59:03]

suggest: s/future date/sentinel/ in the commit msg title and body

LGTM w/ suggestions

https://codereview.appspot.com/294130043/diff/50001/CMakeLists.txt
File CMakeLists.txt (right):

https://codereview.appspot.com/294130043/diff/50001/CMakeLists.txt#newcode478
CMakeLists.txt:478: # set a much further date in the future
suggest: explain why: "Use an improbable date to distinguish from real dates"

https://codereview.appspot.com/294130043/diff/50001/CMakeLists.txt#newcode483
CMakeLists.txt:483: set(VERSION_NUMBER_PATCHLEVEL "${daycount}")
minor: Was the "if (daycount)" handling math errors (like, non-numbers getting
in there)?  Maybe best to keep?

[zhaoqin, 2016-04-04 21:20:36]

Commit log for latest patchset:
---------------
i#1565: set VERSION_NUMBER_PATCHLEVEL even on git log failure

We try different ways to set VERSION_NUMBER_PATCHLEVEL on git log failure.

Review-URL: https://codereview.appspot.com/294130043
---------------

[bruening, 2016-04-04 21:28:02]

LGTM w/ comment

https://codereview.appspot.com/294130043/diff/70001/CMakeLists.txt
File CMakeLists.txt (right):

https://codereview.appspot.com/294130043/diff/70001/CMakeLists.txt#newcode481
CMakeLists.txt:481: # tarball) we use date to get current time for timestamp.
Same comment as for DrM:

I would add something like "This is not ideal as it confuses the build
timestamp with the commit timestamp."

[zhaoqin, 2016-04-04 21:34:20]

https://codereview.appspot.com/294130043/diff/70001/CMakeLists.txt
File CMakeLists.txt (right):

https://codereview.appspot.com/294130043/diff/70001/CMakeLists.txt#newcode481
CMakeLists.txt:481: # tarball) we use date to get current time for timestamp.
On 2016/04/04 21:28:02, bruening wrote:
> Same comment as for DrM:
> 
> I would add something like "This is not ideal as it confuses the build
> timestamp with the commit timestamp."

Done.

[zhaoqin, 2016-04-04 21:36:07]

Committed as
https://github.com/DynamoRIO/dynamorio/commit/b0f8de6bccfcca559de6e704a33104e...

Final commit log: 
---------------
i#1565: set VERSION_NUMBER_PATCHLEVEL even on git log failure

We try different ways to set VERSION_NUMBER_PATCHLEVEL on git log failure.

Review-URL: https://codereview.appspot.com/294130043
---------------