On Sat, Jul 28, 2007 at 12:14:30PM -0700, Matthew Dillon wrote: > I would rather not try to optimize programs to use vfork(). There > just isn't a whole lot of difference between fork and vfork.
When NetBSD implemented a real vfork back around NetBSD 1.4 or so, it made difference in the percent range for a full buildworld. Basically, you can avoid the duplication of the VM space *and* the COW faulting, which sums up. > The GNU configure script crap is just that... crap. In a typical > pkgsrc build that script will probably be run thousands of times, > doing the same tests with slow shell scripts over and over and over > and over and over and over again. It's really the stupidest gnu thing > I've ever seen in my life. It was stupid a decade ago, and its still > stupid today. While a lot of bad things can be said about autoconf, it was the only usable, semi-generic solution for over a decade. There is still only *one* good alternative (and that is using C++...). The biggest complain most maintainers on non-default (from the upstream POV) platform had in all that time was that it is hard to use correctly. E.g. many tests can be done a lot more intelligently than most configure scripts do. Given that autoconf follows the "stand-alone" paradigm (as opposed to imake for some parts of the problem domain), it actually implements it quite well. Joerg
