From owner-freebsd-ports  Fri Apr 25 05:46:34 1997
Return-Path: <owner-ports>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id FAA12644
          for ports-outgoing; Fri, 25 Apr 1997 05:46:34 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA12638;
          Fri, 25 Apr 1997 05:46:20 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id WAA29532; Fri, 25 Apr 1997 22:42:34 +1000
Date: Fri, 25 Apr 1997 22:42:34 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199704251242.WAA29532@godzilla.zeta.org.au>
To: asami@vader.cs.berkeley.edu, bde@zeta.org.au
Subject: Re: yale-tftpd build failure in -current
Cc: ports@freebsd.org, pst@freebsd.org
Sender: owner-ports@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> * Seems unlikely.  Ports makefiles don't use bsd.prog.mk or bsd.lib.mk,
> * right?  I don't intend to merge anything except important bug fixes into
> * 2.2.
>
>This port does:

Urk.  I wonder what it thought of the obj changes.

>===
>## cat Makefile
>...
>classes/libclasses.a:
>        (cd classes ; make)
>
>SUBDIR= classes
>DPADD+= classes/libclasses.a
>LDADD=  classes/libclasses.a
>
>.include <bsd.prog.mk>
>===

The problems are that SUBDIR is misused and DPADD is no longer supported.

SUBDIR doesn't work right because ${PROG} is built in the top-level
(object) directory before the subdirectories are built.  Libraries should
be built first by putting the program directory in SUBDIR after the
library directories (this gives the worse wart that `make' won't know
how to build the library unless `make' is invoked at the top level, but
works well in practice).

DPADD is supposed to be no longer necessary.  dependencies on libraries
are generated automagically by `make depend'.  `make depend' wasn't run,
so there were no dependencies on libraries, so classes/libclasses.a
wasn't built.

Fix: just give the dependency explicitly:

${PROG}: classes/libclasses.a

There is one good reason why DPADD was used instead of giving dependencies
explicitly: dependencies such as

${PROG}: ${LIBUTIL}

don't work because LIBUTIL is defined in bsd.prog.mk which is normally
included last, so ${LIBUTIL} is normally null at the time when dependencies
are evaluated.

Bruce