MacPorts Guide

Mark Duling

Dr. Michael A Maibaum

Will Barton


1. Introduction
2. Installing MacPorts
2.1. Install X11
2.2. Install Xcode Tools
2.3. Install MacPorts
2.4. MacPorts and the Shell
3. Using MacPorts
3.1. The port Command
3.2. Port Variants
3.3. Common Tasks
3.4. Port Binaries
4. Portfile Development
4.1. Portfile Introduction
4.2. Creating a Portfile
4.3. Example Portfiles
4.4. Port Variants
4.5. Patch Files
4.6. Local Portfile Repositories
4.7. Portfile Best Practices
5. Portfile Reference
5.1. Global Keywords
5.2. Global Variables
5.3. Port Phases
5.4. Dependencies
5.5. Variants
5.6. Tcl Extensions
5.7. StartupItems
5.8. Livecheck / Distcheck
5.9. PortGroups
6. MacPorts Internals
6.1. File Hierarchy
6.2. Configuration Files
6.3. Port Images
6.4. APIs and Libs
6.5. The MacPorts Registry
7. MacPorts Project
7.1. Creating Trac Tickets
7.2. Contributing to MacPorts
7.3. Port Update Policies
7.4. MacPorts Membership
7.5. The PortMgr Team
8. MacPorts Guide Terms
Glossary

MacPorts is an easy to use system for compiling, installing, and managing open source software. MacPorts may be conceptually divided into two main parts: the infrastructure, known as MacPorts base, and the set of available ports. A MacPorts port is a set of specifications contained in a Portfile that defines an application, its characteristics, and any files or special instructions required to install it. This allows you to use a single command to tell MacPorts to automatically download, compile, and install applications and libraries. But using MacPorts to manage your open source software provides several other significant advantages. For example, MacPorts:

  • Installs automatically any required support software, known as dependencies, for a given port.

  • Provides for uninstalls and upgrades for installed ports.

  • Confines ported software to a private “sandbox” that keeps it from intermingling with your operating system and its vendor-supplied software to prevent them from becoming corrupted.

  • Allows you to create pre-compiled binary installers of ported applications to quickly install software on remote computers without compiling from source code.

MacPorts is developed on Mac OS X, though it is designed to be portable so it can work on other Unix-like systems, especially those descended from the Berkeley Software Distribution (BSD).

The following notational conventions are used in the MacPorts Guide to distinguish between terminal input/output, file text, and other special text types.

  • Terminal I/O and file text.

    %% Commands to be typed into a terminal window.
    Command output to a terminal window.
    File text.
  • Other special text types.

    A hyperlink: spontaneous combustion.

    A file: /var/log/system.log.

    A command: ifconfig.

    An option: port install

This chapter shows you how to install MacPorts and its prerequisites step-by-step. Note that section 1 and section 2 (installing X11 and Xcode Tools) are Mac OS X specific. If you wish to install MacPorts on another platform, first make sure you have X11 and gcc installed, and then begin at section 3.2 by performing a MacPorts install from source code and proceed to the end of the chapter.

It is recommended that you install the X Window System (X11) even if you don't plan to run X11 applications immediately. Apple's X11 is preferred over either of the X11 ports, XFree86 and Xorg, therefore Apple's X11 is normally used to satisfy ports that depend upon X11 (see non-port dependencies). If Apple's X11 wasn't installed when Mac OS X was installed, follow these steps.

  1. Insert the “Mac OS X Install Disk” and run the package named “Optional Installs”.

  2. At the software selection window expand the Applications category and click the check box beside X11 (and nothing else).

  3. Click Install to install X11.

  4. Drag the /Applications/Utilities/X11 icon to your dock —you must open X11 before launching an X11 application.

If you're using Mac OS X 10.3 then you can download the X11 installer from the Apple download page.

Note

X11 and the X11SDK (from Xcode Tools) are both required for X11 apps. To verify the presence of both, check for files com.apple.pkg.X11User.bom & com.apple.pkg.X11SDKLeo.bom in /Library/Receipts/boms/. On Mac OS X 10.4, look for files X11User.pkg & X11SDK.pkg in /Library/Receipts/.

To launch X11 applications directly from an X11 window (instead of a terminal window), you need to have the MacPorts paths imported into X11 sessions when they are opened. This is a two step process.

First, tell X11 about the ~/.profile file that will be created after you install MacPorts. Do this by editing the file /etc/X11/xinit/xinitrc and adding this line near the top.

source ~/.profile

Now finish the process by making subsequent X11 sessions opened using the menu bar respect your .profile file.

  1. Open X11 and select Customize Menu ... from the Applications menu.

  2. Double-click the menu item Terminal and change: “xterm” to “xterm -ls

  3. Click Done to save the change.

To install Xcode Tools and the X11 SDK, follow these steps.

  1. Download and install the latest version of Xcode Tools from Apple's developer site—do not install it from a Mac OS X install disk unless you've checked for the latest version on Apple's site; older versions of Xcode Tools often cause port install failures.

  2. Run the Xcode Tools package installer.

  3. Click the button Customize, expand the Applications category and click the check box beside X11 SDK to add it to the default items.

  4. Click Install to install Xcode Tools and the X11 SDK.

Note

Xcode Tools are not updated via Mac OS X's Software Update utility.

If you are using Mac OS X, you should install MacPorts using the Mac OS X package installer unless you do not wish to install it to /opt/local/, the default MacPorts location, or if you wish to install a pre-release version of MacPorts base. However, if you wish to install multiple copies of MacPorts or install MacPorts on another OS platform, you must install MacPorts from the source code.

Note

Though a distinction is made between pre-release and release versions of MacPorts base, the ports collection supports no such distinction or versioning. The selfupdate command installs the latest port revisions from subversion (at a slight delay), and updates MacPorts base to the latest released version.

The Mac OS X package installer automatically installs MacPorts, sets the shell environment, and runs a selfupdate operation to update the ports tree and MacPorts base with the latest release.

  1. Download the latest MacPorts-1.x.x.dmg disk image from the MacPorts download directory.

  2. Double-click the MacPorts-1.x.x.pkg package installer on the disk image.

  3. Perform the default “easy” install.

If you installed MacPorts using the package installer, skip this section. To install MacPorts from the source code, follow the steps below.

  1. Download and unzip the latest MacPorts tarball from the MacPorts download directory.

  2. Perform the commands shown in a terminal window. If you wish to use a path other than /opt/local, use the option --prefix and substitute a path for NEW_PREFIX.

    %% cd ~/MacPorts-1.x.x/
    %% ./configure --prefix=NEW_PREFIX  (setting prefix is optional)
    %% make
    %% sudo make install

Occasionally a MacPorts developer may wish to install more than one MacPorts instance on the same host. Only one copy of MacPorts may use the default Tcl library path /Library/Tcl/, so for additional installations use the option --with-tclpackage as shown below and substitute NEW_TCL_PACKAGE with any empty directory, for example /Library/Tcl/macports-new/.

Note

The first command temporarily removes the standard MacPorts binary paths because they must not be present while installing a second instance.

%% export PATH=/bin:/sbin:/usr/bin:/usr/sbin
%% cd ~/MacPorts-1.x.x/
%% ./configure --prefix=NEW_PREFIX --with-tclpackage=NEW_TCLPACKAGE
%% make
%% sudo make install

MacPorts base upgrades are performed automatically (when a newer release is available) during a selfupdate operation. To upgrade a copy of MacPorts that was installed from source to the newer release of the source code, simply repeat the source install with the newer version of the MacPorts source code.

To uninstall MacPorts from the default location /opt/local/, perform these commands from a terminal window.

%% sudo rm -rf /opt/local/
%% sudo rm -rf /Applications/MacPorts/
%% sudo rm -rf /Library/Tcl/macports1.0/
%% sudo rm -rf /Library/LaunchDaemons/org.macports.*

MacPorts requires changes to the shell environment. If MacPorts was installed using the Mac OS X package installer, a “postflight” script was run after installation that places a .profile file in the home directory, which contains the environmental variables required for MacPorts. If a current .profile file exists at installation time it is renamed to “mpsaved_$timestamp”.

Note

If you have either a .bash_login or a .bash_profile file in your home directory, they may take precedence over .profile. You may either remove the previously used file, or add the contents of .profile to it.

The postflight script automatically copies a .profile containing variables according to the rules described below. Those installing MacPorts from source code must modify their environment manually using the rules below as a guide.

Note

Be sure to notice in the rules below that the variables MANPATH and DISPLAY are only needed under certain conditions.

  • A PATH variable is set as shown regardless of platform or environment that appends the MacPorts file paths in front of the default file paths so MacPorts libraries will take precedence over vendor-supplied libraries.

    export PATH=/opt/local/bin:/opt/local/sbin:$PATH
  • A MANPATH variable is set as shown only if a MANPATH variable was already set in a previous .profile that does not include the value ${prefix}/share/man, nor any empty values. Otherwise, it is omitted.

    export MANPATH=/opt/local/share/man:$MANPATH

    Here are some examples of paths that contain empty values:

    /usr/share/man:
    :/usr/share/man
    /usr/share/man::/usr/X11R6/man
  • A DISPLAY variable for X11 application support is set as shown only for Mac OS X versions 10.4 (Tiger) and earlier if a DISPLAY variable is not already set in a .profile active at installation time. A DISPLAY variable is never set for Mac OS X 10.5 (Leopard) or higher.

    export DISPLAY=:0.0

Note

Changes to ~/.profile do not take effect until a new terminal session is opened. Type env in the terminal to verify the current environment settings. Example output for the env command is shown below.

MANPATH=
TERM_PROGRAM=Apple_Terminal
TERM=xterm-color
SHELL=/bin/bash
TERM_PROGRAM_VERSION=237
USER=joebob
__CF_USER_TEXT_ENCODING=0x1FC:0:0
PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin
PWD=/Users/joebob
EDITOR=/usr/bin/pico
SHLVL=1
HOME=/Users/joebob
LOGNAME=joebob
DISPLAY=:0.0
SECURITYSESSIONID=b0cea0
_=/usr/bin/env

This chapter describes using the port command, port variants, common tasks and port binaries.

The MacPorts port command is the main utility used to interact with MacPorts. It is used to update Portfiles and the MacPorts infrastructure, and install and manage ports.

The selfupdate option should be used regularly to sync the local ports tree with the global MacPorts ports repository so you will have the latest port versions. It also checks for new revisions of the MacPorts infrastructure, called MacPorts base, and upgrades it when necessary.

Note

Selfupdate runs only on Mac OS X. If you are running MacPorts on another platform, you must use option sync to update the ports tree; to update MacPorts base you must manually install a newer version from source.

%% sudo port selfupdate

Use the debug flag for verbose output.

%% sudo port -d selfupdate
DEBUG: Rebuilding the MacPorts base system if needed.
DEBUG: Synchronizing ports tree(s)
Synchronizing from rsync://rsync.macports.org/release/ports/
DEBUG: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/release/ports/
receiving file list ... done

[ ... trimmed ... ]


The MacPorts installation is not outdated and so was not updated
DEBUG: Setting ownership to root
selfupdate done!

If selfupdate detects that a newer version of MacPorts base is available, it automatically updates the installed copy of MacPorts base to the latest released version. In that case, you will see the upgrade Makefile execute, and when it finishes you will see this message:

DEBUG: Updating using rsync
receiving file list ... done

Congratulations, you have successfully installed the MacPorts system.

The sync option performs a subset of selfupdate actions. It synchronizes the ports tree, as does selfupdate, but it does not check for upgrades to MacPorts base. On Mac OS X, unless there is a special reason not to do so, you should run selfupdate.

Note

For platforms other than Mac OS X, sync is the only way to get port updates because selfupdate is supported only on Mac OS X.

The list option is used to get a list of all available ports. The list of available ports is very long, so use search if you know a port's name or part of it.

%% port list

The search option is very useful to find port names by partial matches.

%% port search rrd
rrdtool          net/rrdtool       1.2.23    Round Robin Database
php5-rrdtool     www/php5-rrdtool  1.0       PHP 5 glue for RRDtool

The info option is used to get information about a port: description, maintainer, etc.

%% port info flowd
flowd 0.9, net/flowd (Variants: universal, darwin_8)
http://www.mindrot.org/flowd.html

flowd is a small, fast and secure NetFlow collector.

Platforms: darwin
Maintainers: nomaintainer@macports.org

The deps option shows you the dependencies of a port; dependencies are explicitly declared in Portfiles.

%% port deps apache2
apache2 has library dependencies on:
        apr
        apr-util
        expat
        openssl
        pcre

The variants option allows you to check what variations of a port are available before you install it. Variants are a way for port authors to provide options that may be invoked at install time. See Invoking Port Variants below to install ports that have variants.

%% port variants nmap
nmap has the variants:
        universal
        gtk2
        no_ssl
        no_pcre

The option install is used to install a port. See Invoking Port Variants below to install ports that have variants.

%% sudo port install nmap

Note

You may break up a port's installation into smaller steps for troubleshooting by passing port a prior installation phase such as fetch, configure, build, or destroot. See section Port Phases for a complete list of phases.

The option clean deletes all intermediate files that MacPorts creates while building a port. A port clean is also often necessary to remove corrupted tarballs after a failed fetch phase.

%% port clean --all vile

Note

You may also clean files selectively by using options --dist, --archive, or --work.

The uninstall option will uninstall an installed port.

%% port uninstall vile

Note

If a port as installed as a dependency of another port, uninstall will not remove it unless you remove the dependent ports first. To override this behavior, use the -f (force) switch. But some ports need to be rebuilt if dependencies change, so you should know what you are doing if you force uninstall ports.

%% port -f uninstall vile

The contents option displays the files that have been installed by a given port. Uninstalled ports will always show no contents.

%% port contents render
Port render contains:
  /opt/local/include/X11/extensions/render.h
  /opt/local/include/X11/extensions/renderproto.h
  /opt/local/lib/pkgconfig/render.pc
  /opt/local/share/doc/render/library
  /opt/local/share/doc/render/protocol

The installed option displays all installed ports.

%% port installed
The following ports are currently installed:
  aalib @1.4rc5_2 (active)
  apr @1.2.8_0 (active)
  apr-util @1.2.8_2 (active)
  atk @1.18.0_0 (active)

[ ... trimmed ...]

  wxWidgets @2.8.4_2+darwin_8 (active)
  Xft2 @2.1.7_0 (active)
  xrender @0.9.0_0+darwin_8 (active)
  zlib @1.2.3_1 (active)

The outdated option checks your installed ports against the MacPorts repository to see if updated Portfiles have been released since your ports were installed.

%% port outdated
apr                            1.2.8_0 < 1.2.9_0
autoconf                       2.61_0 < 2.61_1
gimp                           2.2.14_0 < 2.2.16_0
libtool                        1.5.22_0 < 1.5.24_0
pkgconfig                      0.21_0 < 0.22_0

The upgrade option upgrades installed ports and their dependencies when a Portfile in the repository has been updated after a port was installed.

%% port upgrade gnome

If you wish not to upgrade a port's dependencies, use the -n switch.

%% port -n upgrade gnome

If you'd like to upgrade all outdated ports, use this command.

%% port upgrade outdated

Note

The upgrade option by default does not uninstall an upgraded port —it deactivates it. See section Port Images, and also Destroot and Activate phases in Port Phases. If you wish to uninstall the old version, use the -u option.

%% port -u upgrade vile

The dependents option reports what ports depend upon a given port, if any. MacPorts learns about dependents during port installation, so uninstalled ports will always report that there are no dependents.

%% port dependents openssl
neon depends on openssl
gnome-vfs depends on openssl
libdap depends on openssl

The livecheck option checks to see if the application corresponding to a given port has been updated at the developer's download site. It's especially useful for port maintainers, but others may also wish to see if a port has the latest available distribution source. See section Livecheck for more information.

%% port livecheck rrdtool
rrdtool seems to have been updated (port version: 1.2.23, new version: 1.3beta1)

Note

If livecheck finds no higher version at the port's download site, it prints nothing. The option -d (debug) may be used for detailed livecheck processing information.

Variants are a way for port authors to provide options for a port that may be chosen during the port install. To display the available variants, if any, use this command:

%% port variants fetchmail
fetchmail has the variants:
        universal
        ssl: Support secure connections using OpenSSL
        fetchmailconf: Install a graphical configurator
        ntlm: Enable NTLM authentication

Note

Variant descriptions are optional, so you may not see descriptions for all variants.

A variant can only be invoked when a port is installed. After you have determined what variants a given port has, if any, you may install a port using the variant as shown.

%% port install fetchmail +ssl

Port variant execution may be verified using the port command with the verbose switch.

%% port -v install fetchmail +ssl

When a port is installed using a valid variant and specified correctly, the verbose output will contain:

DEBUG: Executing variant ssl provides ssl

For an explanation of default variants see Port Variants. Default variants are optional, and not all ports using variants have them. For ports with default variants, you may install a port without them by negating default variants using "-" as shown.

%% port install fetchmail -ssl

To verify that you have properly negated a default variant, you may want to use verbose mode. But negated variants are simply not reported in any way by the port command, as if they did not exist. You will know you have successfully negated the default variant in the example above if you do not see this line in the verbose output.

DEBUG: Executing variant ssl provides ssl

This section lists common operations you may want to perform when managing a MacPorts installation.

TODO: Add content here.

MacPorts can pre-compile ports into binaries so applications need not be compiled when installing on a target system. MacPorts may create two types of binaries: archives and packages.

Binary archives can only be used on a target system running MacPorts. Binary archives allow MacPorts utilities to begin installation after the destroot phase and install and activate a port on the target system. Binary archives are created using the port command as shown.

%% port -d archive logrotate

Debug output is shown below.

--->  Creating logrotate-3.7_0.i386.tgz

[ ... trimmed ... ]

DEBUG:
./
./+COMMENT
./+CONTENTS
./+DESC
./+PORTFILE
./+STATE
./opt/
./opt/local/
./opt/local/etc/
./opt/local/etc/logrotate.conf
./opt/local/man/
./opt/local/man/man8/
./opt/local/man/man8/logrotate.8
./opt/local/sbin/
./opt/local/sbin/logrotate
--->  Archive logrotate-3.7_0.i386.tgz packaged
DEBUG: Executing archive_finish
--->  Archive for logrotate 3.7_0 packaged

Binary archive files are placed in ${prefix}/var/macports/packages/. The archive file type is set in the macports.conf file. The default format is .tgz; other options are: tar, tbz, tbz2, tlz, xar, zip, cpgz, cpio.

Binary packages are standalone binary installers that are precompiled; they do not require MacPorts on the target system. Binary files created with MacPorts may be either .pkg (Mac OS X Installer Packages), or RPM (RPM Package Manager) format. MacPorts may also process a .pkg package into a Mac OS X .dmg disk image file. You may create binary packages with the port command as shown in these examples.

%% port pkg pstree

You may create a Mac OS X .dmg disk image file as shown.

%% port dmg pstree

You may compile a port into an RPM file as shown, in order to install it onto a target that has RPM utilities or a full package management system that can install RPMs.

%% port rpm pstree

All packages are placed in a port's work directory.

Source packages are bundles consisting of a Portfile, patches if needed, and any other files required to install the port. Port source packages are mainly used by developers of package management and port submission frameworks. Port source packages may be in either .portpkg (XAR) or .nosrc.rpm (SRPM) format.

This chapter covers a brief introduction to Portfiles, how to create a local Portfile repository for development, and creating Portfiles.

A MacPorts Portfile is a TCL script that usually contains only the simple keyword/value combinations and Tcl extensions as described in the Portfile Reference chapter, though it may also contain arbitrary TCL code. Every port has a corresponding Portfile, but Portfiles do not completely define a port's installation behavior since MacPorts base has default port installation characteristics coded within it. Therefore Portfiles need only specify required options, though some ports may require non-default options.

A common way for Portfiles to augment or override MacPorts base default installation phase characteristics is by using Portfile phase declaration(s). If you use Portfile phase declaration(s), you should know how to identify the "global" section of a Portfile. Any statements not contained within a phase declaration, no matter where they are located in a Portfile, are said to be in the global section of the Portfile; therefore the global section need not be contiguous. Likewise, to remove statements from the global section they must be placed within a phase declaration.

The main phases you need to be aware of when making a Portfile are these:

  • Fetch

  • Extract

  • Patch

  • Configure

  • Build

  • Destroot

The default installation phase behavior performed by the MacPorts base works fine for applications that use the standard configure, make, and make install steps, which conform to phases configure, build, and destroot respectively. For applications that do not conform to this standard behavior, any installation phase may be augmented using pre- and/or post- phases, or even overridden or eliminated. See Example Portfiles below.

Note

For a detailed description of all port phases, see the Portfile Reference chapter.

Here we list the individual Portfile components for an application that conforms to the standard configure, make, and make install steps of most open source application installs.

  1. Subversion ID tag line

    The first line of a new Portfile must be set as shown. When a port is committed to subversion, ID tags are expanded to include the last person to commit and the commit time.

    # $Id$
  2. PortSystem line

    This statement is required for all ports.

    PortSystem          1.0
  3. Port name

    name                rrdtool
  4. Port version

    version             1.2.23
  5. Port categories

    A port may belong to more than one category, but the first (primary) category should match the directory name in the ports tree where the Portfile is to reside.

    categories          net
  6. Port maintainers

    A port's maintainer is a person or persons who take responsibility for keeping the port up-to-date, and the maintainer keyword lists maintainer email addresses(s). To hide these addresses from spambots, see the more full explanation of the maintainer keyword in the Global Keywords section of the Portfile Reference chapter.

    maintainers         julesverne@example.org

    Note

    The address , or in hidden form , designates a port that may be modified by any committer.

  7. Port description

    description         Round Robin Database
  8. Port long_description

    long_description    RRDtool is a system to store and display time-series \
                        data
  9. A port's application homepage

    homepage            http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
  10. Platform statement

    platforms           darwin
  11. A port's download URLs

    master_sites        http://oss.oetiker.ch/rrdtool/pub/ \
                        ftp://ftp.pucpr.br/rrdtool/
  12. Port checksums

    The checksums specified in a Portfile are checked with the fetched tarball for security. For the best security, use md5, sha1, and rmd160 checksum types.

    checksums           md5 dafa161bc9c61e57636a6085c87c1fe8 \
                        sha1 5da610e1c8bc01b80abc21ab9e98e004363b429c \
                        rmd160 0c1147242adf476f5e93f4d59b553ee3ea378b23

    To find the correct checksums for a port's distribution file, follow this example:

    %% md5 rrdtool-1.2.23.tar.gz
    %% openssl sha1 rrdtool-1.2.23.tar.gz
    %% openssl rmd160 rrdtool-1.2.23.tar.gz
    MD5 ( ... rrdtool-1.2.23.tar.gz) = dafa161bc9c61e57636a6085c87c1fe8
    
    SHA1( ... rrdtool-1.2.23.tar.gz)= 5da610e1c8bc01b80abc21ab9e98e004363b429c
    
    RIPEMD160( ... rrdtool-1.2.23.tar.gz)= 0c1147242adf476f5e93f4d59b553ee3ea378b23
  13. Port dependencies

    A port's dependencies are ports that must be installed before another port is installed.

    depends_lib         port:perl5.8 \
                        port:tcl \
                        port:zlib
  14. Port configure arguments (optional)

    configure.args      --prefix=${prefix} \
                        --enable-perl-site-install \
                        --mandir=${prefix}/share/man

In this section we begin by taking a look at a complete simple Portfile; then we see how to augment default phases by defining pre- and post- phases, how to override default phases, and finally how to eliminate port phases.

# $Id$

PortSystem          1.0

name                rrdtool
version             1.2.23
categories          net
maintainers         julesverne
description         Round Robin Database
long_description    RRDtool is a system to store and display time-series data
homepage            http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
platforms           darwin
master_sites        http://oss.oetiker.ch/rrdtool/pub/ \
                    ftp://ftp.pucpr.br/rrdtool/

checksums           md5 dafa161bc9c61e57636a6085c87c1fe8 \
                    sha1 5da610e1c8bc01b80abc21ab9e98e004363b429c \
                    rmd160 0c1147242adf476f5e93f4d59b553ee3ea378b23

depends_lib         port:perl5.8 \
                    port:tcl \
                    port:zlib

configure.args      --enable-perl-site-install \
                    --mandir=${prefix}/share/man

To augment a port's installation phase, and not override it, you may use pre- and post- installation phases as shown in this example.

post-destroot {
    # Install example files not installed by the Makefile
    file mkdir ${destroot}${prefix}/share/doc/${name}/examples
    file copy ${worksrcpath}/examples/ \
        ${destroot}${prefix}/share/doc/${name}/examples
}

To override the automatic MacPorts installation phase processing, define your own installation phases as shown in this example.

destroot {
    xinstall -m 755 -d ${destroot}${prefix}/bin
    xinstall -m 755 ${worksrcpath}/cdpr ${destroot}${prefix}/bin
}

To eliminate a default phase, simply define a phase with no contents as shown.

build {}

Note

Because many software packages do not use configure, a keyword is provided to eliminate the configure phase. See the chapter Portfile Reference for full information.

Startupitems may be placed in the global section of a Portfile.

startupitem.create      yes
startupitem.name        nmicmpd
startupitem.executable  "${prefix}/bin/nmicmpd"

Startupitems keywords may also be used within a variant definition to make their installation conditional.

variant server {
    startupitem.create  yes
    startupitem.start   "${prefix}/share/${name}/vm-pop3d.init start"
    startupitem.stop    "${prefix}/share/${name}/vm-pop3d.init stop"
}

Variants are a way for port authors to provide options that may be invoked at install time. They are declared in the global section of a Portfile using the "variant" keyword, and should include carefully chosen variant descriptions.

The most common actions for user-selected variants is to add or remove dependencies, configure arguments, and build arguments according to various options a port author wishes to provide. Here is an example of several variants that modify depends_lib and configure arguments for a port.

variant fastcgi description {Add fastcgi binary} {
    configure.args-append \
            --enable-fastcgi \
            --enable-force-cgi-redirect \
            --enable-memory-limit
}

variant gmp description {Add GNU MP functions} {
    depends_lib-append port:gmp
    configure.args-append --with-gmp=${prefix}

}

variant sqlite description {Build sqlite support} {
    depends_lib-append \
        port:sqlite3
    configure.args-delete \
        --without-sqlite \
        --without-pdo-sqlite
    configure.args-append \
        --with-sqlite \
        --with-pdo-sqlite=${prefix} \
        --enable-sqlite-utf8
}

Note

Variant names may contain only the characters A-Z, a-z, and the underscore character “_”. Therefore, take care to never use hyphens in variant names.

In the example variant declaration below, the configure argument --without-x is removed and a number of others are appended.

variant x11 description {Builds port as an X11 program with Lucid widgets} {
    configure.args-delete   --without-x
    configure.args-append   --with-x-toolkit=lucid \
                            --without-carbon \
                            --with-xpm \
                            --with-jpeg \
                            --with-tiff \
                            --with-gif \
                            --with-png
    depends_lib-append      lib:libX11:XFree86 \
                            lib:libXpm:XFree86 \
                            port:jpeg \
                            port:tiff \
                            port:libungif \
                            port:libpng
}

If a variant requires options in addition to those provided by keywords using -append and/or -delete, in other words, any actions that would normally take place within a port installation phase, do not try to do this within the variant declaration. Rather, modify the behavior of any affected phases when the variant is invoked using the variant_isset keyword.

post-destroot {
    xinstall -m 755 -d ${destroot}${prefix}/etc/
    xinstall ${worksrcpath}/examples/foo.conf \
        ${destroot}${prefix}/etc/

    if {[variant_isset carbon]} {
        delete ${destroot}${prefix}/bin/emacs
        delete ${destroot}${prefix}/bin/emacs-${version}
    }
}

Variants are used to specify actions that lie outside the core functions of an application or port, but there may be some cases where you wish to specify these non-core functions by default. For this purpose you may use the keyword default_variants.

default_variants    +foo +bar

Note

The default_variant keyword may only be used in the global Portfile section.

Patch files are files created with the Unix command diff that are applied using the command patch to modify text files to fix bugs or extend functionality.

If you wish to contribute modifications or fixes to a Portfile, you should do so in the form of a patch. Follow the steps below to create Portfile patch files

  1. Make a copy of the Portfile you wish to modify; both files must be in the same directory, though it may be any directory.

    %% cp Portfile Portfile.orig
  2. Edit the file to make it as you want it to be after it is fetched.

  3. Now use the Unix command diff -u to create a "unified" diff patch file. Put the name of the port in the patchfile, for example, Portfile-rrdtool.diff.

    %% diff -u Portfile.orig Portfile > Portfile-rrdtool.diff
  4. A patch file that is a "unified" diff file is the easiest to interpret by humans and this type should always be used for ports. The Portfile patch below will change the version and checksums when applied.

    --- Portfile.orig        2007-07-25 18:52:12.000000000 -0700
    +++ Portfile    2007-07-25 18:53:35.000000000 -0700
    @@ -2,7 +2,7 @@
     PortSystem          1.0
     name                foo
     
    -version             1.4.0
    +version             1.3.0
     categories          net
     maintainers         nomaintainer@macports.org
     description         A network monitoring daemon.
    @@ -13,9 +13,9 @@
     
     homepage            http://rsug.itd.umich.edu/software/${name}
     
     master_sites        ${homepage}/files/
    -checksums           md5 f0953b21cdb5eb327e40d4b215110b71
    +checksums           md5 01532e67a596bfff6a54aa36face26ae
     extract.suffix      .tgz
     platforms           darwin
    

Now you may attach the patch file to a MacPorts Trac ticket for the port author to evaluate.

Necessary or useful patches to application source code should be sent to the application developer (not the port author) so the modifications may be included in the next version; then the port patch may be removed after an updated tarball is released.

  1. Locate the file you wish to patch in its original location within the unpacked source directory and make a duplicate of it.

    %% cd foo-1.34/src
    %% cp Makefile.in Makefile.in.orig
  2. Edit the file to make it as you want it to be after it is fetched.

  3. Now use the Unix command diff -u to create a "unified" diff patch file.

    %% cd foo-1.34
    %% diff -u Makefile.in.orig Makefile.in > patch-Makefile.in

    Note

    You must execute the diff command in the top-level of the unpacked source code. Otherwise the patch command will look for the file to be patched in the wrong place and fail.

  4. A patch file that is a "unified" diff file is the easiest to interpret by humans and this type should always be used for ports. See the example below where a patch adds DESTDIR support to a Makefile.in file.

    --- Makefile.in.orig   2007-06-01 16:30:47.000000000 -0700
    +++ Makefile.in       2007-06-20 10:10:59.000000000 -0700
    @@ -131,23 +131,23 @@
            $(INSTALL_DATA)/gdata $(INSTALL_DATA)/perl
    
     install-lib:
    -       -mkdir -p $(INSTALL_LIB)
    +       -mkdir -p $(DESTDIR)$(INSTALL_LIB)
            $(PERL) tools/install_lib -s src -l $(INSTALL_LIB) $(LIBS)
    -       cp $(TEXT) $(INSTALL_LIB)/
    +       cp $(TEXT) $(DESTDIR)$(INSTALL_LIB)/
  5. Now you may place the patch patch-Makefile.in in the directory ${portpath}/files (either a local repository or after committing to the MacPorts Subversion port repository) and use it in a port using the patchfiles keyword.

    patchfiles          patch-Makefile.in

    Note

    You should create one patch file for each file to be patched, though it is permissible to use existing patches you find that patch multiple files. Patchfile filenames should generally be of the form patch-<directory>-<filename>, as shown in this example: patch-src-Makefile.in.

Though MacPorts applies patch files automatically, you may want to know how to apply patch files manually if you want to test patch files you have created or you wish to apply uncommitted Portfile patches.

  1. Change to the directory containing the file to be patched. In this example, we'll apply a Portfile patch to the postfix port.

    %% cd ${prefix}/var/macports/sources/rsync.macports.org/release/ports/mail/postfix
  2. Now apply the patch that is on the current user's desktop. The patchfile knows the filename of the file to be patched.

    %% patch -p0 < ~/Desktop/Portfile-postfix.diff
    patching file Portfile

To create and test Portfiles that are not yet committed to subversion, you may create a local Portfile repository as shown. Replace the hypothetical user julesverne with your username in the example below.

  1. Open the sources.conf file in a text editor.

    %% cd ${prefix}/etc/macports/
    %% pico sources.conf
  2. Insert a URL pointing to your local repository location before the rsync URL as shown.

    file:///Users/julesverne/ports
    rsync://rsync.macports.org/release/ports
    

    Note

    The file URL should always appear before the rsync URL so that local Portfiles can be tested that are duplicated in the MacPorts tree, because the port command will always operate on the first Portfile it encounters.

  3. Place the Portfiles you create inside a directory whose name matches the port, which should in turn be placed inside a directory that reflect the port's primary category (the first category entry in the Portfile).

    %% cd /Users/julesverne
    %% mkdir -p ports/games/bestevergame
    %% cd ports/games/bestevergame
    %% touch Portfile
  4. After a Portfile is created (see below), use the MacPorts portindex command in the local repository's directory to install it into the Portindex.

    %% cd /Users/julesverne/ports
    %% portindex
    Creating software index in /Users/julesverne/ports
    Adding port games/bestevergame
    
    Total number of ports parsed:   1
    Ports successfully parsed:      1
    Ports failed:                   0

Once the local port is added to the Portindex, it becomes available for searching or installation as with any other Portfile in the MacPorts tree as shown.

%% port search bestever
bestevergame   games/bestevergame 1.1   The Best Ever Game

This section contains practical guidelines for creating Portfiles that install smoothly and provide consistency between ports. The following sections are on the TODO list.

Portfiles may be thought of as a table of keys and values in two columns separated by spaces (not tabs), so you should set your editor to use soft tabs, which are tabs emulated by spaces. By default, the top line of all Portfiles should use a modeline that defines soft tabs for the vim and emacs editors as shown.

# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4

The left column should consist of single words, and will be separated from the more complex right side by spaces in multiples of four. Variable assignments ("set libver") and variant declarations ("variant mysql5") are exceptions, and may be considered a single word on the left side, with a single space between words.

Frequently multiple items are necessary in the second column. For example, to set multiple source download locations, multiple "master_sites" must be defined. Unless the second column items are few and short you should use multiple lines, separate lines with a backslash, and (to emphasize the unity of the block) indent the first line at a deeper level than the following lines as shown in this example.

destroot.keepdirs   ${destroot}${prefix}/var/run \
                    ${destroot}${prefix}/var/log \
                    ${destroot}${prefix}/var/cache/mrtg

TODO: Set variables so changing paths may be done in one place; use them anytime it makes updates simpler: distname ${name}-src-${version}

This chapter serves as a reference for the major elements of a Portfile: port phases, dependencies, StartupItems, variables, keywords, and Tcl extensions.

MacPorts keywords are used to specify required or optional items within a Portfile, or to override default options used by MacPorts base for individual ports. Keywords are to be used within the "global" and "variant" sections of Portfiles, and not within optional port phase declarations.

The global keywords listed below specify information for ports as a whole, whereas the keywords listed under a port phase specify information to be used during a particular installation phase.

PortSystem

The top line of every Portfile; it must be followed by a blank line. It defines which version of the Portfile interpreter will be used.

PortSystem          1.0

name

The name of the Port; it should be lowercase to prevent uninstallation problems due to a macports base bug.

name                foo
version

The version of the ported software.

version             1.23.45
revision

Optional keyword (default is 0) that is used to track port revisions. It should not be incremented for port revisions unless it would benefit users to upgrade an installed port, and cleared when the port is updated to a newer version.

It should be used if a bug in the Portfile was found and all installations of this port have to be updated. If the change only affects new installations, there is no need to increase it.

revision            1
epoch

An optional keyword (default value is 0) that may be used when ports are updated to a version that is numerically less than the previous version. For example 1.10 -> 1.2 or 20070928 -> 1.0. An epoch ensures that port version comparisons work correctly in these cases. Often the epoch is formatted like a date, but it can simply be a number such as 1.

epoch               20080924
epoch               1

Note

An epoch is not needed for most ports. If an epoch is used it must never be decreased or removed even when a port's version is updated; this would cause port version comparisons to be incorrect since epochs take precedence over versions once epochs have been used.

categories

The category under which the ported software falls. The first category should be the same as the directory within which the Portfile is stored; secondary and tertiary categories may be selected.

categories          net security
maintainers

A port's maintainer is a person or persons who take responsibility for keeping the port up-to-date, and the maintainer keyword lists maintainer email addresses(s). However, many maintainers wish to hide these addresses from spambots; to do so follow these conventions:

  • For addresses in domain @macports.org, simply omit the domain name.

  • For addresses in other domains, say , use the convention example.org:account to specify the address.

In the example below, the maintainer email addresses and are hidden using these conventions.

maintainers         jdoe \
                    example.org:julesverne
description

A one-sentence description of the ported software.

description         A classic shooter arcade game.
long_description

A long description of the ported software. Break long lines with escaped newlines.

long_description    A classic shooter arcade game derived from \
                    the game alien-munchers.  Not suitable for \
                    children under two years old.
homepage

Port application's homepage.

homepage            http://www.example.org/apps
platforms

The platforms on which the port has been tested.

platforms           darwin freebsd

Global variables are variables available to any Portfile. For a list of additional variables available to ports that are assigned to a MacPorts Portgroup, see portgroup(7).

All of these variables except prefix are read-only!

prefix

Installation prefix, set in ${prefix}/etc/macports/macports.conf —may be overridden on a per port basis. For example, aqua applications are installed in /Applications/MacPorts.

Default: /opt/local

binpath

Default PATH to use in finding executables.

libpath

Path to the MacPorts TCL libraries.

portpath

Full path to the Portfile location.

Value: work

filesdir

Path to files directory relative to ${portpath}.

Value: files

filespath

Full path to files directory.

Value: ${portpath}/${filesdir}

workpath

Full path to work directory.

Value: ${portbuildpath}/work

worksrcpath

Full path to extracted source code.

Value: ${workpath}/${worksrcdir}

destroot

Full path into which software will be destrooted.

Value: ${workpath}/destroot

distpath

Location to store downloaded distfiles.

Value: ${sysportpath}/distfiles/${dist_subdir}/

install.user

The Unix user at the time of port installation.

install.group

The Unix group at the time of port installation.

os.platform

Identifies platform type (ie "darwin", "freebsd", etc).

os.arch

Identifies hardware type (ie "powerpc", "intel").

os.version

The version number of the host operating system (ie "8.0" for Darwin 8.0).

os.endian

Endianness of the processor (ie "bigEndian").

os.major

The major version number of the host operating system (ie "8" for Darwin 8.0).

x11prefix

Absolute path to X11.

A MacPorts port has ten distinct phases. The MacPorts base is set to perform default steps for applications that use the standard configure, make, and make install steps, but for applications that do not conform to this behavior, installation phases may be declared in a Portfile to augment or override the default behavior as described in the Portfile Development chapter.

fetch

Fetch the ${distfiles} from ${master_sites} and place it in ${prefix}/var/macports/distfiles/${name}.

checksum

Compare ${checksums} specified in a Portfile to the checksums of the fetched ${distfiles}.

extract

Unzip and untar the ${distfiles} into the path ${prefix}/var/macports/build/..../work

patch

Apply optional patch files specified in ${patchfiles} to modify a port's source code file(s).

configure

Execute the command configure in ${workpath}.

build

Execute the command make in ${workpath}.

test

Execute commands to run test suites bundled with a port.

destroot

Execute the command make install DESTDIR=${destroot}in ${workpath}.

Understanding the destroot phase is critical to understanding MacPorts, because, unlike some port systems, MacPorts "stages" an installation into an intermediate location —not the final file destination. MacPorts uses the destroot phase to provide:

  • Port uninstalls - a port's files may be cleanly uninstalled because all files and directories are recorded during install.

  • Multiple port versions may be installed on the same host, since a port's files are not directly inserted into ${prefix} but rather hard-linked into ${prefix} from an intermediate location during a later activation phase.

Note

The DESTDIR variable must be supported in an application's Makefile for the MacPorts destroot phase to work properly. Urge developers to fully support DESTDIR in their Makefiles.

Any empty directories in ${destroot} upon completion of the destroot phase are removed unless a directory name is placed in the value field of the optional destroot.keepdirs keyword.

archive

Use tar to create a tarball of a port's destrooted files and copy it to ${prefix}/var/macports/packages/.

install

Copy a port's destrooted files into ${prefix}/var/macports/software. See Port Images in the MacPorts Internals chapter for details.

activate

Set hardlinks pointing to ${prefix}/var/macports/software to point to ${prefix}.

MacPorts keywords are used to specify required or optional items within a Portfile, or to override default options used by MacPorts base for individual ports. Keywords are to be used within the "global" and "variant" sections of Portfiles, and not within optional port phase declarations.

In other words, port phase keywords are not located within port phase declarations, but rather they refer to port phases and set options for those phases, and they take affect whether or not phase declarations have been explicitly defined in a Portfile.

Keyword list modifiers are keywords that end in -append or -delete. Keywords that support list modifiers are identified under appropriate reference sections below. Keyword list modifiers are most frequently used for these three purposes:

  1. Preserve configure Defaults set by a previously executed Portfile keyword or by MacPorts base

    MacPorts base sets the gcc compiler flags CFLAGS and LDFLAGS for all ports using configure.cflags and configure.ldflags, therefore to keep from overwriting the default compiler flags use configure.cflags-append and configure.ldflags-append.

    • configure.cflags-append

    • configure.ldflags-append

  2. Preserve PortGroup Dependencies

    Ports in a PortGroup have default library dependencies set by MacPorts base. Therefore, never use depends_lib in ports belonging to a PortGroup or it will overwrite the default library dependencies. Instead, use depends_lib-append.

  3. Add or Delete Items for Variants

    When a variant requires more or fewer dependencies, distfiles, or patchfiles, when the variant is invoked you want to add or remove items to the appropriate keyword values list set in the global section of the Portfile. Use the appropriate keywords, for example:

    • depends_lib-append or depends_lib-delete

    • distfiles-append or distfile-delete

    • patchfiles-append or patchfiles-delete

Keywords that support pre_args and post_args are used to assemble command strings together in a row, as described in the reference sections below. But it should be noted that all keyword argument modifiers implicitly support keyword list modifiers. For example, the keyword configure.pre_args also supports configure.pre_args-append and configure.pre_args-delete.

The list of keywords related to the fetch phase.

master_sites

A list of URLs from which a port's download file(s) may be retrieved. For multiple master_sites, they are searched in order until a file matching ${distfile} is found.

  • Default: ???

  • Examples:

    master_sites        http://www.example.org/files/ \
                        http://www.examplemirror.org/example_org/files/
    
    

    You may also use mirror site lists predefined by MacPorts. Here the sourceforge and gnu mirrors are used.

    master_sites        sourceforge gnu
    
    

    When using mirror master_sites, the subdirectory ${name} is checked on every mirror. If the mirror subdirectory does not match ${name}, then you may specify it using after the mirror separated by a colon.

    master_sites        sourceforge:widget \
                        gnu:widget
    
    

    For ports that must fetch multiple download files from different locations, you must label the files with tags and match the tags in a distfiles statement. The format is mirror:subdirectory:tag.

    In the example below, file_one.tar.gz is fetched from sourceforge mirrors in subdirectory ${name}; file tagtwo.tar.gz is fetched from the gnu mirrors in subdirectory sources.

    master_sites        sourceforge::tagone \
                        gnu:sources:tagtwo
    
    distfiles           file_one.tar.gz:tagone \
                        file_two.tar.gz:tagtwo
master_sites.mirror_subdir

Subdirectory to append to all mirror sites for any list specified in ${master_sites}.

  • Default: ${name}

  • Example:

    master_sites.mirror_subdir  magic
patch_sites

A list of sites from which a port's patchfiles may be downloaded, where applicable.

  • Default: ${master_sites}

  • Example:

    patch_sites         ftp://ftp.patchcityrepo.com/pub/magic/patches
patch_sites.mirror_subdir

Subdirectory to append to all mirror sites for any list specified in ${patch_sites}.

  • Default: ${name}

  • Example:

    patch_sites.mirror_subdir   magic
distname

The name of the distribution filename, not including the extract suffix (see below).

  • Default: ${name}-${version}

  • Example:

    distname            ${name}
distfiles

The full distribution filename, including the extract suffix. Used to specify non-default distribution filenames; this keyword must be specified (and tags used) when a port has multiple download files (see master_sites).

  • Default: ${distname}${extract.suffix}

  • Examples:

    distfiles           ${name}-dev_src.tgz
    distfiles           file_one.tar.gz:tagone \
                        file_two.tar.gz:tagtwo
dist_subdir

Create a sub-directory in distpath to store all fetched files.

  • Default: ${name}

  • Example:

    dist_subdir         vim${version}
worksrcdir

Sets the path to source directory relative to workpath. It can be used if the extracted source directory has a different name then the distfile.

  • Default: ${distname}

  • Example:

    worksrcdir          ${name}-src-${version}

Some mirrors require special options for a resource to be properly fetched.

fetch.type

Change the fetch type. This is only necessary if a CVS, svn, or git checkout is be used. standard is used for a normal http or ftp fetch using ${distfiles} and is used as default.

  • Default: standard

  • Values: standard cvs svn git

  • Example:

    fetch.type          svn
    svn.url             svn://example.org
    svn.tag             2100
fetch.user

HTTP or FTP user to fetch the resource.

  • Default: none

  • Example:

    TODO: add example
fetch.password

HTTP or FTP password to fetch the resource.

  • Default: none

  • Example:

    TODO: add example
fetch.use_epsv

Whether to use EPSV command for FTP transfers.

  • Default: yes

  • Example:

    fetch.use_epsv      no
fetch.ignore_sslcert

Whether to ignore the host SSL certificate (for HTTPS).

  • Default: no

  • Example:

    fetch.ignore_sslcert    yes

CVS may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via CVS may cause non-reproducible builds, so it is strongly discouraged.

You have to set fetch.type to cvs to fetch from CVS.

cvs.root

Specify the url from which to fetch files.

  • Default: none

  • Example:

    cvs.root            :pserver:anonymous@cvs.sv.gnu.org:/sources/emacs
cvs.password

Password to login to the CVS server.

  • Default: none

  • Example:

    TODO: add example
cvs.tag

Optional for fetching with CVS, this specifies the code revision to checkout.

  • Default: none

  • Example:

    cvs.tag             HEAD
cvs.date

A date that identifies the CVS code set to checkout.

  • Default: none

  • Example:

    cvs.date            "12-April-2007"
cvs.module

A CVS module from which to check out the code.

  • Default: none

  • Example:

    cvs.module          Sources

Subversion may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Subversion may cause non-reproducible builds, so it is strongly discouraged.

You have to set fetch.type to svn to fetch from svn.

svn.url

This specifies the url from which to fetch files.

  • Default: none

  • Examples:

    svn.url             http://www.domain.com/svn-repo/mydirectory
    svn.url             svn://www.domain.com/svn-repo/mydirectory
svn.tag

Optional tag for fetching with Subversion, this specifies the code revision to checkout; it corresponds to the -r option in the svn cli.

  • Default: none

  • Example:

    svn.tag             37192

Git may be used as an alternative method of fetching distribution files using the keywords in this section. However, fetching via Git may cause non-reproducible builds, so it is strongly discouraged.

You have to set fetch.type to git to fetch from git.

git.url

This specifies the url from which to fetch files.

  • Default: none

  • Examples:

    git.url             git://git.kernel.org/pub/scm/git/git.git
    git.url             http://www.kernel.org/pub/scm/git/git.git
git.branch

Optional tag for fetching with git, this specifies a branch (or other commit-ish) that git should checkout. Note that any branch besides HEAD should be prefixed by origin/.

  • Default: none

  • Example:

    git.branch             72bf1c8
    git.branch             origin/next

The list of keywords related to the checksum phase.

checksums

Checksum(s) of the distribution files. For ports with multiple distribution files, filenames must be included to associate files with their checksums.

All checksum types (md5, sha1 and rdm160) should be used to ensure the integrity of the distfiles.

  • Default: ???

  • Examples:

    checksums           md5 dafa161bc9c61e57636a6085c87c1fe8 \
                        sha1 5da610e1c8bc01b80abc21ab9e98e004363b429c \
                        rmd160 0c1147242adf476f5e93f4d59b553ee3ea378b23
    checksums           ${distname}${extract.suffix} \
                            md5 dafa161bc9c61e57636a6085c87c1fe8 \
                            sha1 5da610e1c8bc01b80abc21ab9e98e004363b429c \
                            rmd160 0c1147242adf476f5e93f4d59b553ee3ea378b23 \
                        hobbit.tar.gz \
                            md5 3b8d02c6cf6239b9bdadbc6543c5a683 \
                            sha1 27874638b23e66d39ed94fe716ca25c967f6e993 \
                            rmd160 82b9991f3bf0ceedbf74c188c5fa44b98b5e40c9

The list of keywords related to the extract phase.

extract.suffix

This keyword is used to specify the extract suffix type.

  • Default: .tar.gz

  • Example:

    extract.suffix      .tgz
use_bzip2

This keyword is for downloads that are tarred and bzipped. When invoked, it automatically sets:

extract.suffix = .tar.bz
extract.cmd    = bzip

  • Default: no

  • Example:

    use_bzip2           yes
use_zip

This keyword is for downloads which are zipped. When invoked, it automatically sets:

extract.suffix    = .zip
extract.cmd       = unzip
extract.pre_args  = -q
extract.post_args = "-d ${portpath}/${workdir}"

  • Default: no

  • Example:

    use_zip             yes
extract.mkdir

This keyword is used to specify if the directory worksrcdir is part of the distfile or if it should be created automatically and the distfiles should be extracted there instead. This is useful for distfiles with a flat structure which would pollute the worksrcdir with lots of files.

  • Default: no

  • Example:

    extract.mkdir       yes
extract.only, extract.only-append, extract.only-delete

List of files to extract into ${worksrcpath}. Only use if default extract behavior is not correct for your port.

  • Default: ${distfiles}

  • Example:

    extract.only        foo.tar.gz
    extract.only-append     bar.tar.gz
    extract.only-delete     foo.tar.gz
extract.cmd

Command to perform extraction.

  • Default: gzip

  • Example:

    extract.cmd         gunzip
extract.args, extract.pre_args, extract.post_args

Main arguments to extract.cmd; additional arguments passed before and after the main arguments.

  • Default: ${distpath}/${distfile}

  • Example:

    extract.args        ${distpath}/${distfile}
    
    

The following argument modifiers are available:

  • extract.pre_args, defaults to: -dc

  • extract.post_args, defaults to: "| tar -xf"

  • Examples:

    extract.pre_args    xf
    extract.post_args   "| gnutar –x"

The list of keywords related to the patch phase.

patch.dir

Specify the base path for patch files.

  • Default: ${worksrcpath}

  • Example:

    patch.dir           ${worksrcpath}/util
patch.cmd

Specify the command to be used for patching files.

  • Default: patch

  • Example:

    patch.cmd           cat
patchfiles, patchfiles-append, patchfiles-delete

Specify patch files to be applied for a port; list modifiers specify patchfiles to be added or removed from a previous patchfile declaration.

  • Default: none

  • Example:

    patchfiles          patch-Makefile.in \
                        patch-source.c
    patchfiles-append   patch-configure
    patchfiles-delete   patch-src-Makefile.in
patch.args, patch.pre_args, patch.post_args

Main arguments to patch.cmd; optional argument modifiers pass arguments before and after the main arguments.

  • Default: none

  • Example:

    patch.args          ???
    
    

The following argument modifiers are available:

  • patch.pre_args, defaults to: -p0

  • patch.post_args, defaults to: none

  • Examples:

    patch.pre_args      -p1
    patch.post_args     ???

The list of keywords related to the configure phase.

MacPorts base sets some important default configure options, so should use the -append version of most configure keywords so you don't overwrite them. For example, MacPorts base sets default configure.cflags so you should always use configure.cflags-append to set additional CFLAGS in Portfiles.

use_configure

Sets if the configure phase should be run. Can be used if the port has no ./configure script.

  • Default: yes

  • Example:

    use_configure    no
configure.env, configure.env-append, configure.env-delete

Set environment variables for configure; list modifiers add and delete items from a previous Portfile configure.env keyword, or a default set by MacPorts base. If available, it is encouraged to use the predefined options (like configure.cflags) instead of modifying configure.env directly.

  • Default: CFLAGS=-I${prefix}/include LDFLAGS=-L${prefix}/lib

  • Example:

    configure.env       QTDIR=${prefix}/lib/qt3
    configure.env-append    ABI=32
    configure.env-delete    TCLROOT=${prefix}
configure.cflags, configure.cflags-append, configure.cflags-delete

Set CFLAGS compiler flags; list modifiers add or delete items from a previous Portfile configure.cflags keyword or the default set by MacPorts base.

  • Default: -O2

  • Example:

    configure.cflags    -Os -flat_namespace
    configure.cflags-append     "-undefined suppress"
    configure.cflags-delete     -O2
configure.ldflags, configure.ldflags-append, configure.ldflags-delete

Set LDFLAGS compiler flags; list modifiers add or delete items from a previous Portfile configure.ldflags keyword or the default set by MacPorts base.

  • Default: -L${prefix}/lib

  • Example:

    configure.ldflags   "-L${worksrcpath}/zlib -lz"
    configure.ldflags-append    "-L/usr/X11R6/lib -L${worksrcpath}/lib"
    configure.ldflags-delete    -L${prefix}/lib/db44
configure.cppflags, configure.cppflags-append, configure.cppflags-delete

Set CPPFLAGS to be passed to the C processor; list modifiers add or delete items from a previous Portfile configure.cppflags keyword or the default set by MacPorts base.

  • Default: -I${prefix}/include

  • Example:

    configure.cppflags  -I${worksrcpath}/include
    configure.cppflags-append   "-I/usr/X11R6/lib -I${worksrcpath}/lib -DHAVE_RRD_12X"
    configure.cppflags-delete   -I${prefix}/lib/db44
configure.cxxflags, configure.cxxflags-append, configure.cxxflags-delete

Set CXXFLAGS to be passed to the C++ processor; list modifiers add or delete items from a previous Portfile configure.cxxflags keyword or the default set by MacPorts base.

  • Default: -O2

  • Example:

    TODO: add example
configure.objcflags, configure.objcflags-append, configure.objcflags-delete

TODO: add description

  • Default: -O2

  • Example:

    TODO: add example
configure.classpath, configure.classpath-append, configure.classpath-delete

TODO: add description

  • Default: ???

  • Example:

    TODO: add example
configure.macosx_deployment_target, configure.macosx_deployment_target-append, configure.macosx_deployment_target-delete

TODO: add description

  • Default: ???

  • Example:

    TODO: add example
configure.fflags, configure.fflags-append, configure.fflags-delete

Set FFLAGS to be passed to the Fortran compiler; list modifiers add or delete items from a previous Portfile configure.fflags keyword or the default set by MacPorts base.

  • Default: -O2

  • Example:

    configure.fflags    -Os
configure.fcflags, configure.fcflags-append, configure.fcflags-delete

Set FCFLAGS to be passed to the Fortran compiler; list modifiers add or delete items from a previous Portfile configure.fcflags keyword or the default set by MacPorts base.

  • Default: -O2

  • Example:

    configure.fcflags   -Os
configure.f90flags, configure.f90flags-append, configure.f90flags-delete

Set F90FLAGS to be passed to the Fortran 90 compiler; list modifiers add or delete items from a previous Portfile configure.f90flags keyword or the default set by MacPorts base.

  • Default: -O2

  • Example:

    configure.f90flags  -Os
configure.cc

Set CC compiler flags for selecting a C compiler.

  • Default: ???

  • Example:

    configure.cc        ${prefix}/bin/gcc-mp-4.2
configure.cpp

Set CPP compiler flags for selecting a C preprocessor.

  • Default: ???

  • Example:

    configure.cpp       /usr/bin/cpp-3.3
configure.cxx

Set CXX compiler flags for selecting a C++ compiler.

  • Default: ???

  • Example:

    configure.cxx       /usr/bin/g++-4.0
configure.objc

Set OBJC compiler flags for selecting an Objective-C compiler.

  • Default: ???

  • Example:

    configure.objc      /usr/bin/gcc-4.0
configure.fc

Set FC compiler flags for selecting a Fortran compiler.

  • Default: ???

  • Example:

    configure.fc        ${prefix}/bin/gfortran-mp-4.2
configure.f77

Set F77 compiler flags for selecting a Fortran 77 compiler.

  • Default: ???

  • Example:

    configure.f77       ${prefix}/bin/gfortran-mp-4.2
configure.f90

Set F90 compiler flags for selecting a Fortran 90 compiler.

  • Default: ???

  • Example:

    configure.f90       ${prefix}/bin/gfortran-mp-4.2
configure.javac

Set JAVAC compiler flags for selecting a Java compiler.

  • Default: ???

  • Example:

    configure.javac