Re: [Boost-build] [Boost-commit] svn:boost r79511 - trunk/tools/build/v2/engine

Subject: Re: [Boost-build] [Boost-commit] svn:boost r79511 - trunk/tools/build/v2/engine
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-07-15 14:39:52

AMDG

On 07/15/2012 08:24 AM, Jurko Gospodnetić wrote:
>   Hi.
> 
>>> Windows Boost Jam implementation now uses finer resolution than
>>> 1 second when creating timestamps based on the current system
>>> time. Since these are never (and should never be!) compared to
>>> file system timestamps - this causes no conflicts with file
>>> system timestamps still using 1 second resolution at best.
>>
>> If they're really disjoint like this, and your
>> special struct is only useful for the current
>> time, then why are you using it for file timestamps?
> 
>   I am actually trying to get the filestamps modeled using a finer
> resolution than 1 second and the aforementioned change seemed like low
> hanging fruit found along the way so I committed it separately.
> 
>   As to why both use-cases are modeled using the same type of objects -
> the concept of holding a 'point in time' seemed the same whether you
> want to track a point in time 'a file was last touched' or a point in
> time 'an external process got started'.
> 
>   The main difference between the two is the source of the time
> information. If you concurrently (A) get it from the file system and (B)
> get it from the current time, there is no guarantee that the timestamps
> will match. E.g. for (A) FAT file system tracks file modification times
> with a 2 s resolution, and for (B) Windows GetSystemTimeAsFileTime() API
> reports the current time with about 15 ms resolution, etc. This means
> that you can get (A) < (B), (A) == (B) or (A) > (B) depending on how OS
> provides the time source of that information independent of whether you
> asked for (A) or for (B) first and there is no guarantee that if you got
> (A) first that its value will be less than (B).
> 
>   I actually have the finer resolution timestamp support implemented for
> Windows on my PC, but fell asleep yesterday trying to see why it caused
> one of the tests (dependency_test.py) to fail... wish I had someone
> besides me for that debugging session... those timestamps, internal file
> scanning targets and their relations to other targets is driving me
> crazy... :-)
> 

-d+12 is helpful for this kind of thing.
It sounds like there could be some kind
of spurious dependency.

>   Best regards,
>     Jurko Gospodnetić
> 
> P.S.
>   Btw. I'm still not positive, but I think there might be a potential
> problem in that dependency_test.py test (and possibly others using the
> same implementation pattern) that is causing it fail sporadically with
> the current implementation but is uncovered completely by using a finer
> timestamp resolution. It creates CPP & H targets from a FOO target in
> its foo.foo rule instead of the foo.foo action. That causes those
> targets to be created every time instead of 'only when needed'.

The print module creates proper updating actions.
It doesn't write the files immediately.

> With the
> original implementation this 'most often makes no difference' because
> those files are created so fast that their timestamps are very close to
> the timestamp of the file requiring them and 1 second timestamp
> resolution rounds them all up nicely to the same value. The problem
> occurs only if their timestamp 'just passes the next 1 second mark' in
> which case they get rounded to the next second. :-)
> 

In Christ,
Steven Watanabe