From owner-freebsd-hackers  Tue Apr  4 15:53:55 1995
Return-Path: hackers-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA25297 for hackers-outgoing; Tue, 4 Apr 1995 15:53:55 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA25290 for <freebsd-hackers@freefall.cdrom.com>; Tue, 4 Apr 1995 15:53:51 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id OAA08510; Tue, 4 Apr 1995 14:52:57 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199504042152.OAA08510@gndrsh.aac.dev.com>
Subject: Re: new install(1) utility
To: nate@trout.sri.MT.net (Nate Williams)
Date: Tue, 4 Apr 1995 14:52:56 -0700 (PDT)
Cc: terry@cs.weber.edu, kargl@troutmask.apl.washington.edu,
        freebsd-hackers@freefall.cdrom.com
In-Reply-To: <199504042123.PAA07372@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 03:23:19 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2500      
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.

I think you better go read /usr/src/include/Makefile:

beforeinstall: ${SHARED}
        @${ECHO} installing ${FILES}
	@-for i in ${FILES}; do \
		cmp -s $$i ${DESTDIR}/usr/include/$$i || \
		    install -c -o ${BINOWN} -g ${BINGRP} -m 444 $$i \
		    ${DESTDIR}/usr/include/$$i; \
	done


> 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 % 

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.

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

This was fixed long ago, it is other headers that we have problems
with this on.  And the other nasty one is the libraries, Bruce has
already discussed all of this on the mailing lists.

> > 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}

...
> 
> Nate
> 


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                   Custom computers for FreeBSD