boost/build
2
0
Fork 0
mirror of https://github.com/boostorg/build.git synced 2026-02-16 01:12:13 +00:00
Code Issues Projects Releases Wiki Activity

Split internal Boost Build testing system's Tester.wait_for_time_change_since_last_build() operation into Tester.wait_for_time_change_since_last_build() and Tester.wait_for_time_change() to allow test code to wait for a timestamp changes unrelated to the last build run.

Browse Source 
[SVN r79736]
This commit is contained in:
Jurko Gospodnetić
2012-07-25 07:10:22 +00:00
parent b13df78c3c
commit 3064f3e71e
1 changed files with 30 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
v2/test/BoostBuild.py
View File

@@ -908,33 +908,49 @@ class Tester(TestCmd.TestCmd):
elements = string.split(name, "/")
return os.path.normpath(apply(os.path.join, [self.workdir]+elements))
def wait_for_time_change_since_last_build(self):
def wait_for_time_change(self, original_timestamp=None):
"""
Wait until newly assigned file system timestamps are larger than the
ones assigned to files created by our previous build run. Used to make
subsequent builds correctly recognize newly created or touched files.
Wait until newly assigned file system timestamps are large enough to
be correctly recognized as newer than the given original timestamp.
This must be recognizable by both this Python based testing framework
and the Boost Jam executable we are testing.
Note: This code assumes that the file system uses a file modification
timestamp resolution no coarser than 1 second. This for example does
not hold on old FAT file systems that used a 2 second file modification
timestamp resolution.
Note: This code assumes that both the file system and the Boost Jam
executable being tested use file modification timestamp resolution no
coarser than 1 second. This for example does not hold on old FAT file
systems that used a 2 second file modification timestamp resolution.
"""
# In theory waiting until for self.last_build_timestamp + 1 should be
# enough here but due to rounding errors in Python's floating point
# timestamp representation, file system's file modification timestamp
# caching and possibly some other OS/Python/file-system layers as well
# it occasionally happens that with just "+ 1" our 'touch' and other
# In theory waiting until original_timestamp + 1 should be enough here
# but due to rounding errors in Python's floating point timestamp
# representation, file system's file modification timestamp caching and
# possibly some other OS/Python/file-system layers as well it
# occasionally happens that with just "+ 1" our 'touch' and other
# commands still do not bump the file time enough to trigger a rebuild.
# To work around this we add an extra tiny wait at the end in case
# there is a chance we are too close to the problematic "+ 1" boundary.
wait_check = lambda x : time.time() < self.last_build_timestamp + x
if original_timestamp is None:
time.sleep(1.1)
return
wait_check = lambda x : time.time() < original_timestamp + x
extra_wait_needed = wait_check(2)
while wait_check(1):
time.sleep(0.1)
if extra_wait_needed:
time.sleep(0.1)
def wait_for_time_change_since_last_build(self):
"""
Wait until newly assigned file system timestamps are large enough to
be correctly recognized as newer than the ones assigned to files
created by our previous build run. This must be recognizable by both
this Python based testing framework and the Boost Jam executable we are
testing. Used to make subsequent builds correctly recognize newly
created or touched files.
"""
self.wait_for_time_change(self.last_build_timestamp)
def __get_current_file_timestamp(self):
fd, path = tempfile.mkstemp(prefix="__Boost_Build_timestamp_tester__")
try: