I just committed this, since we've got a small reprieve from the lock. (infrastructure/build/dpb3 and assorted files)
Nikolai's work has served us well (old dpb), but I thought I could now do better, so I did (we've learnt A LOT with respect to scanning the ports tree over the past few years, especially sqlports). There's a new dpb, totally experimental for 4.7, but very much useful already. It does a lot of new things (then again, there is 4 times as much code). - very simple to use. Can be as easy as dpb3 -a -j4 (use 4 local cores, scan all the ports tree and build it), slightly more complicated as dpb3 -h hosts audio/amarok (scan stuff leading to amarok, and build it using hosts as hosts file). There is a manpage that describes all options. As the old dpb, new dpb still need to scan the ports tree to figure out dependencies, but it considers it as a normal task: it can start building ports as soon as it finds stuff withnout dependencies). New dpb creates lots of logs, specifically it logs all builds as pkgpath AND pkgname, and creates symlinks so that it's easy to find any build. It also closely monitors logs, so that you can see a build getting stuck somewhere (of course, big things like openoffice will still stay for minutes in the extract/package stage, without any log change). New dpb shows a monitor display if you run it inside a tty, so you know what's going on... You can also give it stats from a previous build (e.g., build.log), in which case it will use the log size to give you a % display (assuming the log size doesn't change too much). One ways more useful feature is that it has nice heuristics to try to build things in a smart order: unlock as many ports as early as is possible. If you give it build times from a previous build, it will favor BIG ports. This avoids the classic "oh we're just waiting for openoffice to finish, everything else has been done". The only surprising side-effect is that the build *crawls* at first (well, building qt4, jdk, and gcc 4.2 at the same time is a bit slow), then picks up momentum and speeds up (much lighter ports at the end). The other useful feature is that you can interact with it: when you see an error, you can go and fix the error manually, then remove the error indicator (a lock file) and things will pick up. I can also more or less tune speed information on various machines, so that the slow machines will *never* build big things. There are a few details left to do (for instance, I should detect flaky machines. A machine that stops building things because it's out of disk space *will* grab all ports it can and fail them), but it's taking a nice shape. The fact that it's starting to build things right away also means it's much more fun to setup: you can start it, see a problem, stop, fix the problem, and restart right away (instead of waiting ten minutes to see something failing). Hoping you have as much fun with this as I've had over the past month... ;-)
