On Fri, Feb 7, 2014 at 9:39 PM, Argyrios Kyrtzidis <[email protected]> wrote:
> On Feb 7, 2014, at 12:47 PM, Dmitri Gribenko <[email protected]> wrote:
> I wanted to avoid the need to do the atomic-rename dance.
>
> What is you concern with it ?
No real concerns, just a bit more code to write.
> What is the
> potential for mtime confusion that you see? We could provide a
> function in libclang to get the current timestamp so that clients
> don't have to invent their own, potentially incorrect way to get it.
>
>
> I really want to reduce complexity here and potential for out-of-sync,
> because now you have
>
>
> 1) The builder needs to provide an increasing timestamp by getting clock
> time (or libclang call ?)
> 2) we will compare that clock time with the file system modification time
> which can come from any kind of underlying file system
>
>
> vs
>
> 1) The builder needs to provide an increasing timestamp
>
>
> I much prefer the latter simpler approach.
I can see how clients can break any of these while implementing (1) --
for example, by using the local time instead of UTC time, and having
the build happen when the DST adjustment is made. But (2) is just an
OS-level thing, it can not go wrong.
Also, imagine that we have a good client build system and a bad client
build system. A good client uses correct timestamps, a bad client
uses timestamps + 1 billion. Then after the bad client creates a
module, the good client will never rebuild it, because its timestamps
will always be "in the past".
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <[email protected]>*/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
