I've committed a new compiler selection framework that replaces the
functionality of the old compiler.mk.  If you have any of the following
variables in /etc/mk.conf, then be aware that they're deprecated and
will likely be removed altogether after the next pkgsrc branch date:

	USE_GCC2
	USE_GCC3
	USE_SUNPRO
	USE_MIPSPRO

The way to select the compiler using the new framework is to set
PKGSRC_COMPILER in /etc/mk.conf.  The following is excerpted from
Packages.txt:

---
By default, pkgsrc will use GCC to build packages.  This may be
overridden by setting the following variables in /etc/mk.conf:

 * PKGSRC_COMPILER:
   This is a list of values specifying the chain of compilers to invoke
   when building packages.  Valid values are:

        distcc          distributed C/C++ (chainable)
        ccache          compiler cache (chainable)
        gcc             GNU
        mipspro         Silicon Graphics, Inc. MIPSpro
        sunpro          Sun Microsystems, Inc. WorkShip/Forte/Sun
                        ONE Studio

   The default is "gcc".  You can use ccache and/or distcc with an
   appropriate PKGSRC_COMPILER setting, e.g. "ccache gcc".  This variable
   should always be terminated with a value for a real compiler.

 * GCC_REQD:
   This specifies the minimum version of GCC to use when building
   packages.  If the system GCC doesn't satisfy this requirement, then
   pkgsrc will build and install one of the GCC packages to use instead.
---

The interesting new wrinkle is the ability to use ccache or distcc when
building using pkgsrc, which has implications for bulk-builders and for
users on slower platforms.  Bulk-builders may find that they can use
ccache with a sufficiently large cache to do complete bulk builds
instead of doing incremental bulk builds.  Users on slower platforms
may find they can use distcc and a cross-compiler on a fast i386 box
to accelerate their package building.  Both of these ideas are
unexplored at the moment, but I would be interested in feedback on
these two potential uses allowed by the new framework.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>