From owner-freebsd-hackers Thu Aug 20 14:18:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25304 for freebsd-hackers-outgoing; Thu, 20 Aug 1998 14:18:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25299 for ; Thu, 20 Aug 1998 14:18:18 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.147] (lucky.dynamic.rpi.edu [128.113.24.147]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id RAA51300; Thu, 20 Aug 1998 17:17:47 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: References: Date: Thu, 20 Aug 1998 17:21:45 -0400 To: ac199@hwcn.org From: Garance A Drosihn Subject: Re: proposal to not change time_t Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 4:14 PM -0400 8/20/98, Tim Vanderhoek wrote: >On Thu, 20 Aug 1998, Garance A Drosihn wrote: > >> So, even infinite resolution won't really solve all the >> pathological cases. Completely solving them would get >> rather tricky, and probably involves changes to the 'make' >> command. > > Like locking sources? Assuming you can reliably read-lock sources that you do not have write access to, that could work, and seems like an interesting idea. Not sure how much that would be complicated by things like NFS-mounted drives, but it seems like a pretty reasonable thing for 'make' to do. In fact, when making any target, it could write-lock all targets and read-lock all sources before executing any of the commands to make that target, and then unlock them all when it's done. Actually I was thinking of something more cumbersome, like having 'make' note the lastdatachg time of all sources before making a target, and then doing some sort of check after the target is made to see if the sources had changed. If the sources had not changed, then it ('make') would make sure the lastdatachg time of the target is later than that of all the sources. If some source had changed while the target was being made, well, I guess it should remake it (although I get uneasy about things which automatically decide to "redo" themselves). Basically, I was just waving my hands vaguely in the air, saying that we'd have to do "something" more than have better time resolution, without being really sure what that "something" should be... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message