NetBSD Problem Report #14980
Received: (qmail 24343 invoked from network); 17 Dec 2001 19:53:33 -0000
Message-Id: <200112171952.fBHJqQ904001@home.duh.org>
Date: Mon, 17 Dec 2001 14:52:26 -0500 (EST)
From: tv@pobox.com
Reply-To: tv@pobox.com
To: gnats-bugs@gnats.netbsd.org
Subject: bsd.subdir.mk .WAIT logic has no dependency handling
X-Send-Pr-Version: 3.95
>Number: 14980
>Category: toolchain
>Synopsis: bsd.subdir.mk .WAIT logic has no dependency handling
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: toolchain-manager
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Dec 17 19:54:00 +0000 2001
>Closed-Date:
>Last-Modified: Tue Feb 12 08:57:27 +0000 2002
>Originator: Todd Vierling
>Release: NetBSD 1.5.x, NetBSD-current 20011217
>Organization:
duh.org: Pointing out the obvious since 1994.
>Environment:
See "Release"
>Description:
When the .WAIT logic for <bsd.subdir.mk> was added, no provision for any
kind of dependency handling was given. As a result, you cannot build
a single program that has multiple components, as so:
$ cd src/usr.sbin/dhcp
$ make all-client
In the past, you were able to do just the above, because the recursive
Makefiles would contain lines such as:
all-client: all-common all-minires ...
Since there's now 3 recursive targets that would need this handling (depend,
all, and dependall), this is a little more tricky. However, this SHOULD
be supported again, as building an individual component gets even more
difficult when the dependencies on in-tree libraries are not known for certain
to the builder.
This also has a big impact on parallelism: it's possible to add much more
recursion to parallel builds if the dependencies on the build order are
known at subdirectory recursion time.
>How-To-Repeat:
See "Description"
>Fix:
I've had this on my personal to-do list for a long time, but never got
to making a sane scheme for doing these dependencies. My personal
suggestion would be to provide an extension to the contents of SUBDIR, as
below:
SUBDIR= common1 common2:common1 common3 prog1:common2:common3 \
prog2:common1
The result of this should be dependency rules to the effect of:
all-common2: all-common1
depend-common2: depend-common1
dependall-common2: dependall-common1
all-prog1: all-common2 all-common3
depend-prog1: depend-common2 depend-common3
dependall-prog1: dependall-common2 dependall-common3
all-prog2: all-common1
depend-prog2: depend-common1
dependall-prog2: dependall-common1
The builder could then run "make dependall-prog2", for instance, and get
common1 autobuilt (but not common2 and common3). Note the complete lack
of .WAIT directives; there's *no* need for .WAIT to exist in SUBDIR when
using this scheme.
This scheme is trivial to implement within the <bsd.subdir.mk> .for loop,
but needs peer review before implementation....
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: bin-bug-people->toolchain-manager
Responsible-Changed-By: gnats
Responsible-Changed-When: Tue Feb 12 00:57:25 PST 2002
Responsible-Changed-Why:
There is now a "toolchain-manager" which is the proper default role
account for handling problem reports in the toolchain category.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.