Chapter 4. Slow Porting

Table of Contents
4.1. How Things Work
4.2. Getting the Original Sources
4.3. Modifying the Port
4.4. Patching
4.5. Configuring
4.6. Handling User Input

Ok, so it was not that simple, and the port required some modifications to get it to work. In this section, we will explain, step by step, how to modify it to get it to work with the ports paradigm.

4.1. How Things Work

First, this is the sequence of events which occurs when the user first types make in your port's directory. You may find that having bsd.port.mk in another window while you read this really helps to understand it.

But do not worry if you do not really understand what bsd.port.mk is doing, not many people do... :-)

  1. The fetch target is run. The fetch target is responsible for making sure that the tarball exists locally in DISTDIR. If fetch cannot find the required files in DISTDIR it will look up the URL MASTER_SITES, which is set in the Makefile, as well as our FTP mirrors where we put distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.

  2. The extract target is run. It looks for your port's distribution file (typically a gzipped tarball) in DISTDIR and unpacks it into a temporary subdirectory specified by WRKDIR (defaults to work).

  3. The patch target is run. First, any patches defined in PATCHFILES are applied. Second, if any patch files named patch-* are found in PATCHDIR (defaults to the files subdirectory), they are applied at this time in alphabetical order.

  4. The configure target is run. This can do any one of many different things.

    1. If it exists, scripts/configure is run.

    2. If HAS_CONFIGURE or GNU_CONFIGURE is set, WRKSRC/configure is run.

  5. The build target is run. This is responsible for descending into the port's private working directory (WRKSRC) and building it.

  6. The stage target is run. This puts the final set of built files into a temporary directory (STAGEDIR, see Section 6.1, “Staging”). The hierarchy of this directory mirrors that of the system on which the package will be installed.

  7. The install target is run. This copies the files listed in the port's pkg-plist to the host system.

The above are the default actions. In addition, you can define targets pre-something or post-something, or put scripts with those names, in the scripts subdirectory, and they will be run before or after the default actions are done.

For example, if you have a post-extract target defined in your Makefile, and a file pre-build in the scripts subdirectory, the post-extract target will be called after the regular extraction actions, and the pre-build script will be executed before the default build rules are done. It is recommended that you use Makefile targets if the actions are simple enough, because it will be easier for someone to figure out what kind of non-default action the port requires.

The default actions are done by the bsd.port.mk targets do-something. For example, the commands to extract a port are in the target do-extract. If you are not happy with the default target, you can fix it by redefining the do-something target in your Makefile.

Note:

The main targets (e.g., extract, configure, etc.) do nothing more than make sure all the stages up to that one are completed and call the real targets or scripts, and they are not intended to be changed. If you want to fix the extraction, fix do-extract, but never ever change the way extract operates! Additionally, the target post-deinstall is invalid and is not run by the ports infrastructure.

Now that you understand what goes on when the user types make install, let us go through the recommended steps to create the perfect port.

All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.

Send questions about this document to <freebsd-doc@FreeBSD.org>.