From owner-freebsd-hackers Tue Apr 4 19:07:00 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA29214 for hackers-outgoing; Tue, 4 Apr 1995 19:07:00 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA29208 for ; Tue, 4 Apr 1995 19:06:56 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA25538; Tue, 4 Apr 95 20:00:00 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504050200.AA25538@cs.weber.edu> Subject: Re: new install(1) utility To: nate@sneezy.sri.com Date: Tue, 4 Apr 95 20:00:00 MDT Cc: nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com, freebsd-hackers@freefall.cdrom.com In-Reply-To: <199504050122.TAA08559@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 07:22:59 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk You convinced me (at least for "install -p" for preserve time stamps but set uid/gid/modes) with your post prior to this one. I think we have ended up with interleaved threads here, which makes things a bit more difficult to unravel. > > You could argue that it was then a mistake to rebuild the binary, > > since the generated binary that already exists is newer than the > > source files from which it is derived... > > True, but sometimes header files have changes in them which don't affect > certain binaries, but for safety sake we still must rebuild the binary > because the system has no way of knowing that. Since the binaries > aren't any different, we shouldn't install the binary even though it has > a newer date. Julian put forth a persuasive argument to this effect just recently, and I agree, in theory. My problem is that this is going to change the iden strings in the binary in any case, and the compare will *always* show differences. I don't see a reasonable way around this. > This would clean up the Makefiles which are > hacked to work around a what I consider a deficiency in install, and > allow us to easily add this functionality to other Makefiles like the > libraries versions. I bought off on "-p"; I think that the .mk files could fix a lot of your other arguments, as Rod suggested. > Hmm, I'm getting the feeling that Terry thinks 'cp -p' will solve all of > the world's problems. It won't. See other email. I agree now. See other email. 8-). > Reality check Terry. We are talking about the tools we have today, not > tomorrow. We're not going to modify every build tool in existance so > your perfect dependency world can be satisfied. Oh, cmon, ...please! Can't I have a little bit of peril? 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.