Bob Friesenhahn wrote: > On Thu, 22 Nov 2007, Harlan Stenn wrote: > > I *think* I'd be happy with 'clock skew in the build directory'. > > You mean like > > CPU -- NFS (Sources + Objects) This is one case I know I care about. > or > > NFS1 (Sources) > / > CPU > \ > NFS2 (Built Objects) I haven't used this, but if 'make' on the CPU system will have one idea of timestamps, and files on NFS1 and/or NFS2 can show clock skew that will affect how 'make' on CPU runs, then yes. > or > > Local Disk (Sources) > / > CPU > \ > NFS2 (Built Objects) Again, if 'make' on CPU system will be adversely affected by clock skew on NFS2 then this should be checked. > or > > NFS1 (Sources) > / > CPU > \ > Local Disk (Built Objects) As above. > I use the last one quite often these days but sometimes I use the > first. There seems to be several issues here. Is the following a usefully sufficient question to ask: If I touch a file now, how far off is the timestamp on the file I touch from what I think the time is? Taking your above examples into consideration, there is the added complication of "what if srcdir is unwritable?" > >> When my clocks are a bit off I have noticed that > >> GNU make sometimes intermittently complains due to the "wandering > >> clock" problem. > > > > I don't see 'wander' (case insensitive) in either the gmake 3.81 or > > 3.79.1 source trees. > > What I mean is that the condition is borderline detectable so > sometimes it is detected and other times not. Yes, this all boils down to the meaning of "detectable". At the moment, I am inclined to think that if 'make' will detect it, then I care. And this is clearly an insufficient definition. Perhaps the 'check-clock-skew' program would have a "useful" default threshhold, and there could be an option to specify a different threshhold. H _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
