Subject: New compiler selection framework committed
To: None <tech-pkg@NetBSD.org>
From: Johnny C. Lam <jlam@NetBSD.org>
List: tech-pkg
Date: 02/01/2004 02:15:35
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>