On Feb 7, 2014, at 2:55 PM, Dmitri Gribenko <[email protected]> wrote:
> On Fri, Feb 7, 2014 at 10:36 PM, Argyrios Kyrtzidis <[email protected]> > wrote: >> >> On Feb 7, 2014, at 1:56 PM, Dmitri Gribenko <[email protected]> wrote: >> >> On Fri, Feb 7, 2014 at 9:54 PM, Argyrios Kyrtzidis <[email protected]> >> wrote: >> >> On Feb 7, 2014, at 1:46 PM, Dmitri Gribenko <[email protected]> wrote: >> >> 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”. >> >> >> 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. >> >> >> A bad client will only create a problem for itself if clang uses >> filesystem mtime on the timestamp file. >> >> >> 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 ? > > Sure, will do. Do you think that we could also add a separate binary > / a mode in clang to print it to use in build systems that don't embed > libclang? This can be added later if needed. > > 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
