Subject: Re: make: making .WAIT recursive
To: None <>
From: Aaron J. Grier <>
List: tech-toolchain
Date: 02/15/2006 21:55:25
On Mon, Feb 13, 2006 at 10:17:51PM +0000, David Laight wrote:
> That is actaully the crux of the problem.
>     a: b .WAIT c
>     c: d
> ends up being equivalent to
>     a: b c
>     c: b d
> and nothing stops make building 'b' and 'd' at the same time.
> However there are many cases where you need to have build 'b' before
> 'c' can build, but working out whether to build 'b' is expensive, and
> you need to build 'c' much more often.
> Then the makefiles needs three targets that:
> 1) builds just 'b'
> 2) builds 'c' assuming that 'b' is correctly made
> 3) builds both 'b' and 'c'
> The target for '3' is the one that causes grief.

.WAIT and .BARRIER seem to dance around the issue of missing dependency
expression rather than fixing it.

the crux of the problem is that make can only do its job properly if
dependencies are properly expressed to it.  .WAIT and .BARRIER are
_hacks_ and shortcuts around that.  if 'b' takes a long time to figure
out if it needs to be built, reduce the number of dependencies for 'b'.
if you don't want to express the dependencies, then fail with 'don't
know how to make b' and leave it.

these sorts of shortcuts are only tempting long-term maintenance issues
and artificial bottleneck surprises as parallelism increases.

there have been concerns that reading, parsing, and calculating the
dependency tree of the 3752 makefiles (in netbsd-3) would take too long,
(without any hard numbers to back these claims), but somehow doing a
recursive make and parsing those files individually and not correctly
expressing inter-directory dependencies is acceptable.

  Aaron J. Grier | "Not your ordinary poofy goof." |
              "silly brewer, saaz are for pils!"  --  virt