From owner-freebsd-hackers Tue Apr 4 16:26:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA26155 for hackers-outgoing; Tue, 4 Apr 1995 16:26: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 QAA26141 for ; Tue, 4 Apr 1995 16:26:06 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA08021; Tue, 4 Apr 1995 17:29:41 -0600 Date: Tue, 4 Apr 1995 17:29:41 -0600 From: Nate Williams Message-Id: <199504042329.RAA08021@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, freebsd-hackers@freefall.cdrom.com Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > 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. > > I think Terry means this: > > ${DESTDIR}${BINDIR}${PROG}: ${.OBJDIR}/${PROG} > install ${COPY} ${STRIP} -m ${BINMODE} -o ${BINOWN} -g ${GINGRP} \ > ${PROG} ${DESTDIR}${BINDIR} > > install: ${DESTDIR}${BINDIR}${PROG} Ahh, but what if ${DESTDIR}${BINDIR}${PROG} was older than ${.OBJDIR}/${PROG} simply because it was deleted during a purge of /usr/obj. My arguement is that it doesn't *need* to be installed (especially in the case of libraries). An include file change in one file will cause all of the libraries to be re-compiled that depend on it, but it doesn't *necessarily* mean that there were any changes in the library or it's functionality. If the libraries don't differ at a binary level, there weren't any changes, so they library doesn't need to be installed. Nate