From owner-freebsd-current  Mon Jul 15 18:56:48 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA13184
          for current-outgoing; Mon, 15 Jul 1996 18:56:48 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA13173
          for <current@freebsd.org>; Mon, 15 Jul 1996 18:56:44 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id LAA28339; Tue, 16 Jul 1996 11:55:34 +1000
Date: Tue, 16 Jul 1996 11:55:34 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607160155.LAA28339@godzilla.zeta.org.au>
To: bde@zeta.org.au, imp@village.org
Subject: Re: Nits
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Cool.  So setenv INSTALL "install -C" should do the trick for me
>before I build, right?  I should also be able to put this in
>/etc/make.conf, if I read sys.mk correctly.

>Without that hack, it took 1:11:35 to do a make all install.  I'll
>have to see what delta that has on the build time.

It will probably take longer :-).  The main benefits of not clobbering
the timestamps are that you and dump(8) can tell what has really changed
simply by looking at the timestamps.

>Also, should I bother with make depend?  It takes another hour on my
>machine.  It seems that there should be an easy way to tell if the

Yes.  It shouldn't take long to redo it, especially if you don't run
`make depend' separately (`make depend all' sometimes uses out of date
dependencies).

>.depend file is out of date or not.  Will have to think about this

I don't think there is an easy way.  To be complete, it is necessary to
check the timestamps of all the source files, including all the headers
referenced in .depend.  `make depend' now only checks the timestamps of
the primary sources.

>because I want to use the feature, but not pay so high a price when 20
>files in the whole system have changed.  Or does this fall into the
>category of "always do a make depend, or we'll not help you if you get
>an odd failure" category?

Yes.

Bruce