The current approach to setting timestamps can cause confusing errors building the vendored memcached in situations where the clock has drifted a bit from real time. The failed sanity check produces the error:
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock
This kind of clock drift is very common when using Docker for Mac or Windows. Ruby's Time.now appears to use a different clock from the one used by the timestamps for the file created as a part of the sanity check. As a result, a clock drift of as little as six seconds can cause the timestamps set on the source tree to be newer than the file created during the sanity check.
The bug that this was meant to fix doesn't seem to be an issue anymore; I'm not seeing ./configure within the vendored memcached attempt to run autoconf. I think the timestamp code can safely be removed.
The current approach to setting timestamps can cause confusing errors building the vendored memcached in situations where the clock has drifted a bit from real time. The failed sanity check produces the error:
This kind of clock drift is very common when using Docker for Mac or Windows. Ruby's Time.now appears to use a different clock from the one used by the timestamps for the file created as a part of the sanity check. As a result, a clock drift of as little as six seconds can cause the timestamps set on the source tree to be newer than the file created during the sanity check.
The bug that this was meant to fix doesn't seem to be an issue anymore; I'm not seeing
./configure
within the vendored memcached attempt to run autoconf. I think the timestamp code can safely be removed.