On Mon, 29 Jan 2001, Alistair Crooks wrote:

> On Mon, Jan 29, 2001 at 09:19:10AM -0500, Todd Vierling wrote:
> > 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 bsd.pkg.mk.  There are outstanding
> > : > complaints as to the ultra-recursion nature of bsd.pkg.mk.  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 bsd.pkg.mk 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 bsd.pkg.mk, and the overhead involved in
> > having another make(1) plus another /bin/sh invoked for every recursion.
> > This optimization deserves its own category.
> 
> I have not vastly underestimated the number of recursion points, since
> I have nowhere provided an estimate of their number. 
> 
> > Recursion in bsd.pkg.mk is the reason it takes *hours*, not minutes, to
> > build README.html on ftp.netbsd.org; it also accounts for a nontrivial
> > amount of time in a bulk build.

as far as bulk builds, I've got code which helps a lot which I hope to
commit soon.


-Dan