On Fri, Oct 13, 2006 at 07:51:18PM +0200, Hauke Fath wrote:
> Looking at a typical pkgsrc build on a Mac, much time is spent working
> through layers and layers of pkgsrc wrappered wrapper-wrapped-scripts
> and Makefiles calling Makefiles calling...  you get the drift. At the
> bottom end is a GNU configure script that works out time and again
> with glacial speed volatile information like the return type of
> printf, and the size of 'int'.

there is certainly a subset of these which could be cached, but a lot of
them cannot be, since they are features which are added by a previous
library installation, and may vary between ./configure instantiations.
pkgsrc simply doesn't track dependencies (especially version numbers) as
closely as would be required to completely avoid running ./configure.

however, priming the cache for system-wide defaults (like sizeof(int))
should be quite straightforward and could be put into the existing
pkgsrc framework.  (possibly even build.sh.)  I'd love to implement
this, but it's quite unlikely given all the other projects on my list...

> I suspect there is not that much time to be saved by exporting (takes
> time, too) the compiler jobs. OTOH, the fifteen minutes that -current
> gcc 4 needed _per_file_ on my Quadra 650 when building devel/ddd were
> truly impressive...

has anybody here tried setting up distcc for cross-compiling m68k on a
remote machine?  or doing a bulkbuild under an emulator?

> The problem here is that a machine which is not self-hosted has no
> show-case for its use anymore - I'll leave out embedded hardware, for
> obvious reasons.

the machines that are having difficulties self-hosting have had such
difficulties even before the base system could be cross-compiled.  a
system which takes a week to natively build its own world when new
machines take a couple hours (if that), it arguably belongs behind glass
in a "show-case" at museum.

> This is actually a downside of NetBSD being cross-buildable: It
> increases the risks of carrying bugs over several releases, simply
> because per definition there is no MD showstopper bug anymore, the
> distribution can always be built elsewhere.

lack of resources and interest to discover and fix bugs bugs is what
causes them to carry over several releases.  cross-buildability only
makes the lack of resources available for supporting old platforms
painfully obvious.

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