The make fetch stage gets the source code, or distfiles, for the port. First, it looks in any directories specified by the mk.conf variable $DISTDIR. If this variable isn’t set, it looks in the directory specified by the shell environment variable $DISTDIR. If neither variable is set, it looks in /usr/ports/distfiles. If make fetch finds the distribution files and thinks that they’re the correct version, it hands control to the next requested stage, and the build continues.

If the source code is not on the local machine, make fetch tries to download it from an Internet site specified in the port’s makefile as MASTER_SITES. (You can customize download locations, as discussed in Customizing Ports.)

You’ll find the make fetch command very useful when there are certain times in your day when you can download more easily than other times. For example, I have a T1 to my house,^[38] but my employer’s office has roughly 66 times as much bandwidth as I have at home. I can run make fetch on my laptop while visiting my employer, go home, and build the port in peace. (And the boss thinks I come in because he buys lunch.)

The make checksum stage verifies that distfiles have not been corrupted, either by the download process or maliciously. OpenBSD includes several different checksums for each distfile, but only checks that the SHA-256 checksum matches the distfile. If the checksum matches, the build proceeds to the next stage. If the checksums do not match, the build immediately aborts. The build will not continue until you find a distfile that matches the checksum.

Not all software developers are conscientious about updating the names of their distfiles when they update their software. For these software packages, the foo-1.0.tgz file the port developer downloaded in the morning might differ from the foo-1.0.tgz file you download later that same day. Perhaps the original software author thought that no one would notice, but the OpenBSD folks would, if only via the logic built into the ports tools. After all, the ports system can’t tell the difference between a source file quietly modified by the software author and a source file quietly modified by an intruder. If you get a distfile that doesn’t match the recorded checksum, try to fetch a matching file by setting the REFETCH variable to true.

# make checksum REFETCH=true

Now make will walk through all the distfile sources listed in the port, downloading them successively in an effort to find a distfile that matches that used by the port developer.

If you are absolutely certain that the file you downloaded is the correct, untampered-with one, but it still doesn’t pass make checksum, you’re wrong. If you know that you’re wrong, but you really do want to install compromised or damaged software, set the environment variable NO_CHECKSUM=yes to skip the make checksum stage.

At this point, the ports system gets into recursion. At make prepare, the port checks for any software needed to build or run the software you’re trying to build. If the port lists any of these dependencies, it checks to see if they are installed. If the dependencies are not installed, this stage kicks off make install for those required ports. Once all of the required dependencies are installed, this stage ends.

The ports system must extract the source code from the distfile before building the software. Source code is extracted into the directory defined by $WRKOBJDIR, or in a directory under /usr/ports/pobj/ named after the port. By default, my tcsh port would extract under /usr/ports/pobj/tcsh, but because I defined a separate location for building software, it’s built under /home/ports/wrkobjdir/tcsh.

Any patches included in the port’s patches directory are applied in the make patch stage. If the patches all apply correctly, this stage ends. If the patches do not apply correctly, the port fails.

To apply your own patches to the port, or to review the code before compiling it, run make patch first. Your patches might conflict with the port patches if you apply them first, cause compilation failures, or bring up any number of other problems. By running make patch first, you get to see the code as OpenBSD can compile it. Anything you break after that is definitely your fault.

Many software packages use a configure script to prepare themselves for compilation on a specific platform. The make configure command runs that script. If you want to edit the configure script, do so before running this stage! If there is no configure script, the port silently skips this stage.

The make build stage compiles the fetched, extracted, patched, and configured software. If you type make in a port directory, the port calls make build. This stage doesn’t assemble a package; it just performs the compilation and creates the actual program binaries in the port’s work directory.

The make fake stage installs the software in a subdirectory, laid out exactly as it would be under the root directory. This fake root directory is in the work directory, named fake- with the architecture appended, such as fake-amd64. Everything that will be in the package is installed under this directory, with the same ownership and permissions that it will include in the package.

The make package stage bundles up the port’s fake installation directory, adds in packaging and installation instructions, and ties it all up in a package exactly like those available on the FTP site. The package will be stored under the PKGREPO directory you defined earlier (or in /usr/ports/packages if you didn’t define one), in a subdirectory organized by architecture, and in further subdirectories organized by available distribution locations.

make package means that you can build this port on one machine without installing it. You must install the build dependencies to build the port, however.

The make install stage runs pkg_add(1) to install the package you compiled.

Some packages require a lot of disk space. The make clean stage removes all of the build files except the distfile and the completed package.