Fine Control of Ports01/04/2001
In this episode, we pick up right where I left of in the last article.
The ports system includes other useful options, all documented in
bsd.port.mk. The one I use most often is
make clean, which removes the port's build directory, source code, and object files. Once every few months, I go to each active system and do
cd /usr/ports && make clean; this recursively purges all of the object files on the system and can free up quite a bit of disk space.
make deinstall and
make reinstall commands uninstall and reinstall the software. If you're testing a port, deciding if you want to use a piece of software, or generally mucking around, this is the easiest way to uninstall and reinstall a port. You can't use these targets after
If you run many FreeBSD systems and like to tweak ports during the build process,
make package is your friend. You can compile the software just as you like it in the ports tree, and
make package will create a standard FreeBSD package for you. You can copy the package over to other systems and install it at will.
Previously in Big Scary Daemons:
If you have limited bandwidth at one location but lots of bandwidth elsewhere,
make fetch-recursive is your friend. You can download the source code for a port and all its dependencies before even starting to build. For a long time, my phone line at home limited my connection speed to 14.4. I had a T1 at work. I could take my laptop in, do a
cd /usr/ports/x11/kde2 && make fetch-recursive. When I got home, I could do
cd /usr/ports/x11/kde2 && make install clean. When I got up the next day, I had the latest KDE installed. (I use WindowMaker, but kdegames is nice.) This is also useful if you're charged for your time online.
make fetch-recursive option is kind of dumb; it doesn't check to see if you already have a dependency installed before fetching the source. If you have a metered connection, this isn't a good option.
You can customize your environment to control port-building behavior as well. Rather than specifying each of these on the command line, however, you can set make environment variables in
/etc/make.conf. This helps enforce your "system policy" for that machine; you might not touch a system for months and forget where you put things.
PORTSDIR is the location of your ports tree. On more than one occasion I've filled up
/usr; slapping in a second hard drive, moving the ports tree, and setting
PORTSDIR is a quick and easy fix for this.
WRKPREFIXDIR is where the port creates the "work" directory. The port extracts source code, builds object files, and does all its other work here. If I set
WRKPREFIXDIR=/home/mwlucas/work, I can build a port as non-root.
WRKPREFIXDIR makes the port build a subdirectory structure under the selected directory; for example, if I build
games/xsol with the environment above, the port actually builds in
/usr/home/mwlucas/work/usr/ports/games/xsol/work/xsol-new. I can avoid building the whole subtree by setting
NO_WRKSUBDIR, forcing the port to build in
LINUXBASE directories indicate where to install a port.
X11BASE is where X11-based ports go, and
LINUXBASE is where Linux-compatibility-based ports go.
LOCALBASE is where everything else goes. You can override them all simultaneously with the
PREFIX variable. (This doesn't always work in ports that use
imake, part of the X11 system.)
DISTDIR variable is where the port puts and/or checks for the source code. This defaults to
DISTDIR allows you to put it anywhere you like.
DISTDIR, an administrator can allow unprivileged users to install their own versions of ports. While they can't bind to privileged IP ports or run with greater privileges, they can still do a great deal of experimentation and research with ports.
MASTER_SITES controls where the port fetches its source from. By setting
MASTER_SITE to the site of a known good source code tarball, you can control where the port downloads from. For example, if you use the command
make MASTER_SITE=ftp://ftp2.freebsd.org/pub/FreeBSD/distfiles, then
fetch will attempt to pull the
distfile directly from that site.
If you want to pull the
distfile directly from a FreeBSD repository, you can specify
MASTER_SITE_FREEBSD=YES. The distfile probably exists there. Most FreeBSD mirrors are already heavily loaded, so please avoid this.
Probably the most useful option for maintainers of large FreeBSD networks is
MASTER_SITE_OVERRIDE. The network administrator can build a central repository of important distfiles on a local server. The site listed in
MASTER_SITE_OVERRIDE is checked for distfiles before any remote sites are contacted. This saves on exterior bandwidth and makes fetching distfiles more reliable.
Other environment variables affect how ports are compiled. Many ports include options to compile with support for various functions or integrate with other ports.
One of the most helpful of these is
WITHOUT_X11. Many headless workstations neither run X nor need the X libraries. If you set this, ports that have a choice will build without X. This can keep you from building X on these systems. (Of course, if you build a port that requires X, it'll recursively build XFree86 anyway.)
Software such as QT, GTK, and Gnome are fairly pervasive, and many newer ports give options whether or not to compile with support for them. This is indicated by a string such as
USE_QT in the port's makefile. If as a matter of system policy you use QT whenever possible, you can edit
/etc/make.conf to include
Some of the most common of these include:
USE_JAVA USE_PYTHON USE_RUBY
Similarly, some ports allow special configuration if you use Emacs. If you set
EMACS_PORT_NAME="emacs", the port will use Emacs 19.34. If you have
EMACS_PORT_NAME="emacs20", the port uses Emacs 20.7.
With this information under your belt, you're ready to make some changes to a port. We'll look at that in the next article.
Read more Big Scary Daemons columns.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.