<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;">On Feb 7, 2014, at 12:47 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br><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 6:31 PM, Argyrios Kyrtzidis <<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>> wrote:<br><blockquote type="cite">+def fmodules_skip_verify_if_validated_after : Joined<["-"],<br>"fmodules-skip-verify-if-validated-after=">,<br><br>Should we use a more general name, like “-fbuild-session-timestamp” or<br>something, this seems like it could have other uses in the future.<br></blockquote><br>I like the current name because clang does what the option name says.<br>If build session timestamp could be used for more features, I'd prefer<br>to have two options then:<br><br>-fbuild-session-timestamp=... -fmodules-validate-once-per-build-session<br></div></blockquote><div><br></div><div>Ok, fair enough.</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><blockquote type="cite">+static void updateModuleTimestamp(ModuleFile &MF) {<br>+  // Overwrite the timestamp file contents so that file's mtime changes.<br>+  std::string TimestampFilename = MF.getTimestampFilename();<br>+  std::string ErrorInfo;<br>+  llvm::raw_fd_ostream OS(TimestampFilename.c_str(), ErrorInfo);<br>+  if (!ErrorInfo.empty())<br>+    return;<br>+  OS << "Timestamp file\n";<br>+}<br><br>+    New->InputFilesValidationTimestamp = 0;<br>+    if (New->Kind == MK_Module) {<br>+      std::string TimestampFilename = New->getTimestampFilename();<br>+      llvm::sys::fs::file_status Status;<br>+      // A cached stat value would be fine as well.<br>+      if (!FileMgr.getNoncachedStatValue(TimestampFilename, Status)) {<br>+        llvm::sys::TimeValue MTime = Status.getLastModificationTime();<br>+        New->InputFilesValidationTimestamp =<br>+            MTime.toEpochTime() * 1000 + MTime.milliseconds();<br>+      }<br>+    }<br>+<br><br>I’m concerned that we are depending on being in-sync with the modification<br>time given by the file system and the builder that provided the original<br>timestamp.<br></blockquote><br>I wanted to avoid the need to do the atomic-rename dance.</div></blockquote><div><br></div><div>What is you concern with it ?</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;">  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></div></blockquote><div><br></div><div>I really want to reduce complexity here and potential for out-of-sync, because now you have</div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><br></div><div>1) The builder needs to provide an increasing timestamp by getting clock time (or libclang call ?)</div></div><div><div>2) we will compare that clock time with the file system modification time which can come from any kind of underlying file system</div></div></blockquote><div><div><br></div><div>vs</div><div><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>1) The builder needs to provide an increasing timestamp</div></div></blockquote><div><div><br></div><div>I much prefer the latter simpler approach.</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>>*/<br><br>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a></div></blockquote></div><br></body></html>