[PATCH] Verify source files for a module only once during the build

[Argyrios Kyrtzidis]

On Feb 7, 2014, at 2:55 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:

> On Fri, Feb 7, 2014 at 10:36 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>> 
>> On Feb 7, 2014, at 1:56 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> 
>> On Fri, Feb 7, 2014 at 9:54 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
>> wrote:
>> 
>> On Feb 7, 2014, at 1:46 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> 
>> On Fri, Feb 7, 2014 at 9:39 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
>> wrote:
>> 
>> On Feb 7, 2014, at 12:47 PM, Dmitri Gribenko <gribozavr at gmail.com> 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 <gribozavr at gmail.com>*/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140207/f59b0436/attachment.html>