From owner-freebsd-current  Sat Aug 24 22:08:16 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA05801
          for current-outgoing; Sat, 24 Aug 1996 22:08:16 -0700 (PDT)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA05794
          for <current@freebsd.org>; Sat, 24 Aug 1996 22:08:13 -0700 (PDT)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id WAA04448; Sat, 24 Aug 1996 22:07:06 -0700 (PDT)
To: Bruce Evans <bde@zeta.org.au>
cc: current@freebsd.org
Subject: Re: DEPEND and/or NO_DEPEND broken 
In-reply-to: Your message of "Sun, 25 Aug 1996 13:57:15 +1000."
             <199608250357.NAA19669@godzilla.zeta.org.au> 
Date: Sat, 24 Aug 1996 22:07:06 -0700
Message-ID: <4446.840949626@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> bsd.prog.mk and bsd.prog.mk now have ${DEPEND} in the dependencies for
> the `all' target, but ${DEPEND} is usually null at this point.

Hmmmm.  You're right, though I'm perplexed that I didn't catch this
during my testing of NO_DEPEND.  In any case...

> The caching effect of making dependencies at the "same" time as objects
> could be obtained by changing (simplifying) the SUBDIR processing to
> pass all targets to the sub-makes.  (Run `make -n depend all install' in

OK.

> overlooked, but good enough in most cases.  The SUBDIR processing could
> even be changed to special- case the `depend' target so that `make
> depend all' is split into `make depend; make all' for subdirectories.

Ugh.

> wouldn't work in general (in particular, in leaf directories).  The
> SUBDIR processing might need to special-case only the `depend' target so
> that the other targets don't get messed up.  OTOH, `make all install'
> would probably benefit from it too.  E.g., libraries would be installed
> earlier so programs would be linked to up to date versions of the
> libraries.

Hmmm.  I think this is one of those things that's far easier to
demonstrate than explain, since I'm still not entirely sure that what
I'm inferring from the above is what you actually mean.  Would you
perhaps have some diffs which explain this in a more practical
fashion? :-)

					Jordan