<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 7, 2014, at 1:56 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Fri, Feb 7, 2014 at 9:54 PM, Argyrios Kyrtzidis <<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>> wrote:<br><blockquote type="cite">On Feb 7, 2014, at 1:46 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br><br><blockquote type="cite">On Fri, Feb 7, 2014 at 9:39 PM, Argyrios Kyrtzidis <<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>> wrote:<br><blockquote type="cite">On Feb 7, 2014, at 12:47 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br>I wanted to avoid the need to do the atomic-rename dance.<br><br>What is you concern with it ?<br></blockquote><br>No real concerns, just a bit more code to write.<br><br><blockquote type="cite">What is the<br>potential for mtime confusion that you see? We could provide a<br>function in libclang to get the current timestamp so that clients<br>don't have to invent their own, potentially incorrect way to get it.<br><br><br>I really want to reduce complexity here and potential for out-of-sync,<br>because now you have<br><br><br>1) The builder needs to provide an increasing timestamp by getting clock<br>time (or libclang call ?)<br>2) we will compare that clock time with the file system modification time<br>which can come from any kind of underlying file system<br><br><br>vs<br><br>1) The builder needs to provide an increasing timestamp<br><br><br>I much prefer the latter simpler approach.<br></blockquote><br>I can see how clients can break any of these while implementing (1) --<br>for example, by using the local time instead of UTC time, and having<br>the build happen when the DST adjustment is made. But (2) is just an<br>OS-level thing, it can not go wrong.<br><br>Also, imagine that we have a good client build system and a bad client<br>build system. A good client uses correct timestamps, a bad client<br>uses timestamps + 1 billion. Then after the bad client creates a<br>module, the good client will never rebuild it, because its timestamps<br>will always be "in the past”.<br></blockquote><br>A bad client will always be a problem but this is the responsibility of the builder, if the builder timestamps are self-consistent we don’t need to worry about any time changes or adjustments or what have you, it will not even need to be time based, we just don’t care.<br></blockquote><br>A bad client will only create a problem for itself if clang uses<br>filesystem mtime on the timestamp file.<br></div></blockquote><div><br></div><div>Ok, I retract my objections but with the current approach we definitely need a libclang API to control what gets passed in with the option (and provide a convenient way to “get it right”), could you add that ?</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Dmitri<br><br>--<span class="Apple-converted-space"> </span><br>main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/</div></blockquote></div><br></body></html>