Subject: Re: Bad definition of USE_LIBTOOL in
To: Alistair Crooks <>
From: Todd Vierling <>
List: tech-pkg
Date: 01/29/2001 09:19:10
On Mon, 29 Jan 2001, Alistair Crooks wrote:

: > : I don't do it, but notice that the ".if make(...)"'s prevent the
: > : dependency from being registered at install or package time, so it's
: > : not so bad.
: >
: > We have to avoid using ".if make()" in  There are outstanding
: > complaints as to the ultra-recursion nature of  We need to
: > eliminate spots where the "target being made" is referenced, so that
: > changing some of those recursions into dependencies will be possible.

: It's well-known that there are a number of ways to speed up pkgsrc, the most
: popular of which seem to be (in order)
: 1. avoid using != command expansion where possible, passing any results
: down through the environment
: 2. cut down on the number of `cmd` invocations
: 3. split itself into sub-files, and include only the sub-parts
: of it which need to be included
: 4. lots more radical micro-optimisations
: and I'd include your optimisation in (4), in lieu of any direct benchmarked
: numbers.

No, eliminating recursion goes into (2) -- although its performance impact
exceeds everything you have listed here.  You vastly underestimate the
number of recursion points in, and the overhead involved in
having another make(1) plus another /bin/sh invoked for every recursion.
This optimization deserves its own category.

Recursion in is the reason it takes *hours*, not minutes, to
build README.html on; it also accounts for a nontrivial
amount of time in a bulk build.

About 2 years ago, I had a pet project that eliminated almost all the
recursions and used proper make(1) dependencies (`newpkgsrc').  Rather than
taking 10-20 seconds *on a nonloaded system* to go through a package with
entirely null extract, patch, configure, and build targets, the modified took *2* seconds.  I'd consider that quite significant.

-- Todd Vierling <>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --