From owner-freebsd-hackers  Tue Apr  4 14:19:54 1995
Return-Path: hackers-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA23668 for hackers-outgoing; Tue, 4 Apr 1995 14:19:54 -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 OAA23660 for <freebsd-hackers@freefall.cdrom.com>; Tue, 4 Apr 1995 14:19:50 -0700
Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id PAA07372; Tue, 4 Apr 1995 15:23:19 -0600
Date: Tue, 4 Apr 1995 15:23:19 -0600
From: Nate Williams <nate@trout.sri.MT.net>
Message-Id: <199504042123.PAA07372@trout.sri.MT.net>
In-Reply-To: terry@cs.weber.edu (Terry Lambert)
       "Re: new install(1) utility" (Apr  4,  2:35pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: terry@cs.weber.edu (Terry Lambert)
Subject: Re: new install(1) utility
Cc: kargl@troutmask.apl.washington.edu, freebsd-hackers@freefall.cdrom.com
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> > > Hmmm... this could produce a decent timesavings.
> > 
> > Yes, this would in effect do the same thing as the -t option you have
> > now and save a tremendous amount of re-linking of files since the
> > timestamps would not change.
> 
> Bah humbug.
> 
> 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.

Now, we have

trout:/usr/user/nate % ls -l /usr/include/stdio.h
-r--r--r--  1 bin  bin  12938 Apr  4 15:19 /usr/include/stdio.h
trout:/usr/user/nate % 

And any program which has stdio.h in it's dependency lists will need to
be recompiled.

> And jamming make-like dependency capability into install is a
> cockamamy way to fix it.

It has nothing to do with make-like dependency capabilities.  With the
addition of that option, install now determines if it really needs to
install the files rather than blindly doing it no matter what.

> Much better (if one must hack on install) to cause intermediately
> created directories when installing a target to be owned by the
> specified user and group instead of being owned by the installer
> (hint: this would fix a number of X install problems).

This is orthogonal to the entire discussion, and why you are bringing it
up is beyond me.  Have you been talking with J. Monroy lately?


Nate