From owner-freebsd-hackers Tue Apr 4 16:06:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA25620 for hackers-outgoing; Tue, 4 Apr 1995 16:06:25 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA25609 for ; Tue, 4 Apr 1995 16:06:16 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA07852; Tue, 4 Apr 1995 17:09:33 -0600 Date: Tue, 4 Apr 1995 17:09:33 -0600 From: Nate Williams Message-Id: <199504042309.RAA07852@trout.sri.MT.net> In-Reply-To: "Rodney W. Grimes" "Re: new install(1) utility" (Apr 4, 2:52pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Rodney W. Grimes" Subject: Re: new install(1) utility Cc: terry@cs.weber.edu, kargl@troutmask.apl.washington.edu, freebsd-hackers@freefall.cdrom.com Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > The problem is improper dependency graphs in the makefile. > > > > Huh? Methink you don't understand the problem Mr. Lambert. > > > > trout:/usr/user/nate % ls -l /usr/include/stdio.h > > -r--r--r-- 1 bin bin 12938 Nov 22 04:38 /usr/include/stdio.h > > trout:/usr/user/nate % > > > > Now, if I got into /usr/src/include and do a 'make install' > > the date of that file will change due to the install copying the file in > > /usr/include over top of the old file, even though they are the same file > > in all respects. > > I think you better go read /usr/src/include/Makefile: Oh, I know that it already does a check. I was assuming that the check wasn't being done since Terry's arguement was that the compare step wasn't necessary because the bug was in the dependency graphs in the makefile. I was proposing moving the check *into* install for effeciency reasons, and then we could use it for more than just the include files. > You happened to have picked a bad example. There are include files > that this holds true for, and that is due not really having good > support in the *.mk files for a includes: rule. I would rather > see the above type of thing folded into the .mk files and not > muck with the install binary. Putting it in the install binary allows us to do this more effeciently. Yes, we could put it in the .mk files, but install already knows the sizes of both the original and the new files, so doing an update is obvious if they don't match, and doing cksums on both files would be much faster than the 'cmp' IMHO. [ Rest of the argument about stdio *NOT* getting changed deleted ] The point I was trying to make was that *NOT* installing things if there aren't any changes is a good thing to do, and shouldn't be limited to just the include files. Let's bloat up install to do it. *grin* > And the other nasty one is the libraries, Bruce has already discussed > all of this on the mailing lists. See above. Modifying install would be one (good) way of avoiding these problems. We are adding a bit more smarts to install is all. Nate