5.3. Port Phases

5.3. Port Phases
Prev	Chapter 5. Portfile Reference	Next

Single Page Chunked

5.3. Port Phases

5.3.1. Introduction
5.3.2. Installation Phase Keywords
5.3.3. Fetch Phase Keywords
5.3.4. Checksum Phase Keywords
5.3.5. Extract Phase Keywords
5.3.6. Patch Phase Keywords
5.3.7. Configure Phase Keywords
5.3.8. Build Phase Keywords
5.3.9. Test Phase Keywords
5.3.10. Destroot Phase Keywords

5.3.1. Introduction

The MacPorts port installation process has a number of distinct phases that are described in detail in this section. The default scripts coded into MacPorts base performs the standard +configure+, +make+, and +make install+ steps. For applications that do not conform to this standard, 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 ${configure.cmd} in +${worksrcpath}+.
build: Execute ${build.cmd} in +${worksrcpath}+.
test: Execute commands to run test suites bundled with a port, available only for a fraction of ports. This is an optional phase, run only if +port test+ is executed, and always works with a build from source, not a binary. A failure is only for the user’s information, and does not block a subsequent installation from the build.
destroot: Execute the command +make install++DESTDIR=${destroot}+in +${worksrcpath}+.

Note

Using a DESTDIR variable is a part of standard GNU coding practices, and this variable must be supported in an application’s install routines for MacPorts' destroot phase to work without manual Portfile scripting or source patching. Urge developers to fully support DESTDIR in their applications.

+ Understanding the destroot phase is critical to understanding MacPorts, because, unlike some package management 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.
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.
install
Archive a port’s destrooted files into ${prefix}/var/macports/software. See Port Images in the MacPorts Internals chapter for details.
activate
Extract the port’s files from the archive in ${prefix}/var/macports/software to their final installed locations, usually inside +${prefix}+.

5.3.2. Installation Phase Keywords

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 effect whether or not phase declarations have been explicitly defined in a Portfile.

5.3.2.1. Keyword List Modifiers (-append, -delete, -replace, -strsed)

Keyword list modifiers are keywords that end in -append, -delete or -replace. Keywords that support list modifiers are identified under appropriate reference sections below.

-append adds a value to the keyword, -delete removes a previously added item. -replace takes two arguments and replaces the first value from the keyword with the second value. -strsed treats the keyword value as a string and filters it through strsed using the given pattern. There is also a deprecated syntax for -replace which takes only one argument and behaves the same as -strsed.

Keyword list modifiers are most frequently used for these three purposes:

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
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+.
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 or depends_lib-replace distfiles-append or distfiles-delete or distfiles-replace ** patchfiles-append or patchfiles-delete or patchfiles-replace

5.3.2.2. Keyword Argument Modifiers (.pre_args / .post_args)

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+.

5.3.3. Fetch Phase Keywords

The list of keywords related to the fetch phase.

master_sites

A list of URLs from which a port’s ${distfiles} may be retrieved.

Keyword values for master_sites may include predefined site lists known as “mirrors”, such as sourceforge, gnu, etc. The file(s) declared in ${distfiles} will be fetched from one of the locations defined in +master_sites+, while trying to find the best reachable mirror for the user’s connection.

For a complete list of mirrors and their list of sites, see the file mirror_sites.tcl located in _resources/port1.0/fetch/ in the ports tree.

Note

If a master_sites keyword has multiple values, after any mirrors are expanded the list of sites is sorted by ping response times. The sites are then tried in sorted order until matching ${distfiles} are found.

Default: none (but the macports_distfiles mirror is always implicitly appended)
Examples:
```
master_sites        https://www.example.org/files/ \
                    https://mirror.example.org/example_org/files/
```
You may also use mirror site lists predefined by MacPorts. Here the sourceforge, gnu, and freebsd mirrors are used.
```
master_sites        sourceforge gnu freebsd
```
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 to a distfiles keyword. 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
The last path component of +${distpath}+. Override it to store multiple ports' distfiles in the same directory (such as multiple ports providing different versions of the same software), or if a stealth update has occurred.
Default: ${name}
Examples:
```
dist_subdir         gcc
```
```
dist_subdir         ${name}/${version}_1
```
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. Also used if the source to be built is in a subdirectory.
Default: ${distname}

Examples:

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

worksrcdir          ${distname}/src

5.3.3.1. Advanced Fetch Options

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

fetch.type

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

Default: standard
Values: standardbzr+cvs++git++hg++svn+

Example:

fetch.type          svn
svn.url             svn://example.org
svn.revision        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
```

5.3.3.2. Fetch from BZR

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

The bzrfetch.type is used to fetch source code from a bzr repository.

bzr.url

This specifies the url from which to fetch files.

Default: none

Examples:

bzr.url             lp:inkscape

bzr.url             lp:~callelejdfors/pycg/trunk

bzr.revision

Optional tag for fetching with bzr, this specifies the revision to checkout

Default: -1 (the last committed revision)
Example:
```
bzr.revision          2209
```

5.3.3.3. Fetch from CVS

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.

The cvsfetch.type is used to fetch source code from a CVS repository.

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:
```
cvs.password        nice-password
```

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
```

5.3.3.4. Fetch from Git

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.

The gitfetch.type is used to fetch source code from a git repository.

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             https://www.kernel.org/pub/scm/git/git.git

git.branch

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

Default: none

Example:

git.branch             72bf1c8

git.branch             origin/next

5.3.3.5. Fetch from Mercurial

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

The hgfetch.type is used to fetch source code from a Mercurial repository.

hg.url

This specifies the url from which to fetch files.

Default: none

Examples:

hg.url              https://www.kernel.org/hg/index.cgi/linux-2.6/

hg.url              http://hg.intevation.org/mercurial

hg.tag

Optional tag which should be fetched. Can be a Mercurial tag or a revision. To prevent non-reproducible builds use of tip as revision is discouraged.

Default: tip

Example:

hg.tag              v1.3

hg.tag              ceb884843737

5.3.3.6. Fetch from Subversion

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.

The svnfetch.type is used to fetch source code from an svn repository.

svn.url

This specifies the url from which to fetch files.

Default: none

Examples:

svn.url             https://www.example.com/svn-repo/mydirectory

svn.url             svn://svn.example.com/svn-repo/mydirectory

svn.revision

Optional tag for fetching with Subversion, this specifies the peg revision to checkout; it corresponds to the @REV syntax of the svn cli.

Default: none
Example:
```
svn.revision        37192
```

svn.method

Optional tag for fetching with Subversion, this specifies whether to check out the code into a working copy, or just export it without the working copy metadata. An export is preferable because it takes half the disk space, but some software expects to be built in a working copy (for example because it wants to record the revision number into itself somewhere).

Default: export
Example:
```
svn.method          checkout
```

5.3.4. Checksum Phase Keywords

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. Each checksum entry should also indicate the file’s size.

At least two checksum types (typically rmd160 and sha256) should be used to ensure the integrity of the distfiles.

Default: none

Examples:

checksums           rmd160  0c1147242adf476f5e93f4d59b553ee3ea378b23 \
                    sha256  baf8a29ff721178317aac7b864c2d392b1accc02de8677dd24c18fd5717bf26e \
                    size    1039840

checksums           ${distname}${extract.suffix} \
                        rmd160  0c1147242adf476f5e93f4d59b553ee3ea378b23 \
                        sha256  883715307c31ae2c145db15d2404d89a837f4d03d7e6932aed21d1d1f21dad89 \
                        size    2429530 \
                    hobbit.tar.gz \
                        rmd160  82b9991f3bf0ceedbf74c188c5fa44b98b5e40c9 \
                        sha256  2c3afd16915e9f8eac2351673f8b599f5fd2ff9064d4dfe61f750d72bab740b3 \
                        size    8594032

5.3.5. Extract Phase Keywords

The list of keywords related to the extract phase.

extract.asroot

This keyword is used to specify that the extract phase should be done as the root user.

Default: no
Example:
```
extract.asroot      no
```

extract.suffix

This keyword is used to specify the extract suffix type.

Default: .tar.gz
Example:
```
extract.suffix      .tgz
```

use_7z

This keyword is for downloads that are compressed using the 7z algorithm. When invoked, it automatically sets:

extract.suffix = .7z
extract.cmd    = 7za

Default: no
Example:
```
use_7z           yes
```

use_bzip2

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

extract.suffix = .tar.bz2
extract.cmd    = bzip

Default: no
Example:
```
use_bzip2           yes
```

use_lzip

This keyword is for downloads that are compressed using the lzma algorithm. When invoked, it automatically sets:

extract.suffix    = .tar.lz
extract.cmd       = lzip

Default: no
Example:
```
use_lzip             yes
```

use_lzma

This keyword is for downloads that are compressed using the lzma algorithm. When invoked, it automatically sets:

extract.suffix    = .lzma
extract.cmd       = lzma

Default: no
Example:
```
use_lzma             yes
```

use_tar

This keyword is for downloads that are uncompressed tar archives. When invoked, it automatically sets:

extract.suffix    = .tar
extract.cmd       = tar
extract.pre_args  = -xf

Default: no
Example:
```
use_tar             yes
```

use_zip

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

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

Default: no
Example:
```
use_zip             yes
```

use_xz

This keyword is for downloads that are compressed using the xz tool. When invoked, it automatically sets:

extract.suffix    = .tar.xz
extract.cmd       = xz

Default: no
Example:
```
use_xz             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

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

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"

5.3.6. Patch Phase Keywords

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

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-destdir-variable-fix.diff \
                    patch-source.c.diff

patchfiles-append   patch-configure.diff
patchfiles-delete   patch-destdir-variable-fix.diff

patch.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     ???

5.3.7. Configure Phase Keywords

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.cmd

Selects the command to be run in the default configure phase.

Default: ./configure
Example:
```
configure.cmd       ./config.sh
```

configure.env

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.optflags

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

Default: -Os

Example:

configure.optflags    -O2

configure.optflags-append     -finline-functions
configure.optflags-delete     -Os

configure.cflags

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: ${configure.optflags}

Example:

configure.cflags    -Os -flat_namespace

configure.cflags-append     "-undefined suppress"
configure.cflags-delete     -O2

configure.ldflags

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 -Wl,-headerpad_max_install_names

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

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

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: ${configure.optflags}
Example:
```
TODO: add example
```

configure.objcflags

TODO: add description

Default: ${configure.optflags}
Example:
```
TODO: add example
```

configure.classpath

TODO: add description

Default: ???
Example:
```
TODO: add example
```

configure.macosx_deployment_target

TODO: add description

Default: ???
Example:
```
TODO: add example
```

configure.fflags

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: ${configure.optflags}
Example:
```
configure.fflags    -Os
```

configure.fcflags

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: ${configure.optflags}
Example:
```
configure.fcflags   -Os
```

configure.f90flags

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: ${configure.optflags}
Example:
```
configure.f90flags  -Os
```

configure.cc

C compiler for the CC environment variable when invoking the configure script.

Default: ???

Example:

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

configure.cpp

C preprocessor for the CPP environment variable when invoking the configure script.

Default: ???
Example:
```
configure.cpp       /usr/bin/cpp-3.3
```

configure.cxx

C++ compiler for the CXX environment variable when invoking the configure script.

Default: ???
Example:
```
configure.cxx       /usr/bin/g++-4.0
```

configure.objc

Objective-C compiler for the OBJC environment variable when invoking the configure script.

Default: ???
Example:
```
configure.objc      /usr/bin/gcc-4.0
```

configure.fc

Fortran compiler for the FC environment variable when invoking the configure script.

Default: ???

Example:

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

configure.f77

Fortran 77 compiler for the F77 environment variable when invoking the configure script.

Default: ???

Example:

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

configure.f90

Fortran 90 compiler for the F90 environment variable when invoking the configure script.

Default: ???

Example:

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

configure.javac

Java compiler for the JAVAC environment variable when invoking the configure script.

Default: ???
Example:
```
configure.javac     ${prefix}/bin/jikes
```

configure.compiler

Select a compiler suite to fill the compiler environment variables. All variables/tools a compiler suite can provide are set. Manually set variables are not overwritten. Keep in mind that not all compiler suites might be available on your platform: gcc-3.3 is available on Mac OS X 10.3 and 10.4 PowerPC, gcc-4.0 is available on 10.4 and 10.5, gcc-4.2 and llvm-gcc-4.2 are available on 10.5 and 10.6, and clang is available on 10.6 and later.

Only use it if a port really needs a different compiler.

Default: apple-gcc-4.2 on Mac OS X 10.4
Default: gcc-4.2 with Xcode 3.x on Mac OS X 10.5 and 10.6
Default: llvm-gcc-4.2 with Xcode 4.0 through 4.2 on Mac OS X 10.6 and 10.7
Default: clang with Xcode 4.3 and later on OS X 10.7 and later
Values: gcc-3.3gcc-4.0+gcc-4.2++llvm-gcc-4.2++clang++macports-clang-3.3++macports-clang-3.4++macports-clang-3.7++macports-clang-3.8++macports-clang-3.9++macports-clang-4.0++macports-clang-5.0++macports-clang-6.0++apple-gcc-4.0++apple-gcc-4.2++macports-gcc-4.3++macports-gcc-4.4++macports-gcc-4.5++macports-gcc-4.6++macports-gcc-4.7++macports-gcc-4.8++macports-gcc-4.9++macports-gcc-5++macports-gcc-6++macports-gcc-7++macports-gcc-8+
Example:
```
configure.compiler  macports-gcc-4.5
```

configure.perl

Set PERL flag for selecting a Perl interpreter.

Default: ???

Example:

configure.perl      ${prefix}/bin/perl5.26

configure.python

Set PYTHON flag for selecting a Python interpreter.

Default: ???

Example:

configure.python    ${prefix}/bin/python2.7

configure.ruby

Set RUBY flag for selecting a Ruby interpreter.

Default: ???
Example:
```
configure.ruby      ${prefix}/bin/ruby
```

configure.install

Set INSTALL flag for selecting an install tool; used for copying files and creating directories.

Default: /usr/bin/install

Example:

configure.install   ${prefix}/bin/ginstall

configure.awk

Set AWK flag for selecting an awk executable.

Default: ???
Example:
```
configure.awk       ${prefix}/bin/gawk
```

configure.bison

Set BISON flag for selecting a bison executable, a parser generator.

Default: ???
Example:
```
configure.bison     /usr/bin/bison
```

configure.pkg_config

Set PKG_CONFIG flag for helping find pkg_config, a tool for retrieving information about installed libraries.

Default: ???

Example:

configure.pkg_config    ${prefix}/bin/pkg-config

configure.pkg_config_path

Set PKG_CONFIG_PATH flag for telling pkg_config where to search for information about installed libraries.

Default: ${prefix}/lib/pkgconfig:${prefix}/share/pkgconfig

Example:

configure.pkg_config_path   ${python.prefix}/lib/pkgconfig

configure.args

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

Default: none

Example:

configure.args      --bindir=${prefix}/bin

The following argument modifiers are available:

+configure.pre_args+, defaults to: --prefix=${prefix}
+configure.post_args+, defaults to: none

Examples:

configure.pre_args  --prefix=${prefix}/share/bro
configure.post_args OPT="-D__DARWIN_UNIX03"

5.3.7.1. Configure Universal

Universal keywords are used to make a port compile on OS X for multiple architectures.

Note

There is a default universal variant made available to all ports by MacPorts base, so redefining universal keywords should only be done to make a given port compile if the default options fail to do so.

configure.universal_args

Arguments used in the configure script to build the port universal.

Default: --disable-dependency-tracking
Example:
```
TODO: add example
```

configure.universal_cflags

Additional flags to put in the CFLAGS environment variable when invoking the configure script. Default value is based on +${configure.universal_archs}+.

Default:
(PowerPC Tiger) -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc
(Intel Tiger / Leopard) -arch i386 -arch ppc
(Snow Leopard and later) -arch x86_64 -arch i386
Example:
```
TODO: add example
```

configure.universal_cppflags

Additional flags to put in the CPPFLAGS environment variable when invoking the configure script.

Default:
(PowerPC Tiger) -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk
(others) none
Example:
```
TODO: add example
```

configure.universal_cxxflags

Additional flags to put in the CXXFLAGS environment variable when invoking the configure script. Default value is based on +${configure.universal_archs}+.

Default:
(PowerPC Tiger) -isysroot ${developer_dir}/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc
(Intel Tiger / Leopard) -arch i386 -arch ppc
(Snow Leopard and later) -arch x86_64 -arch i386
Example:
```
TODO: add example
```

configure.universal_ldflags

Additional flags to put in the LDFLAGS environment variable when invoking the configure script.

Default:
(PowerPC Tiger) -Wl,-syslibroot,${developer_dir}/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc
(Intel Tiger / Leopard) -arch i386 -arch ppc
(Snow Leopard and later) -arch x86_64 -arch i386
Example:
```
TODO: add example
```

5.3.7.2. Automake, Autoconf, and Autoreconf

The list of configure keywords available for ports that need automake and/or autoconf.

use_autoreconf

Whether or not to use autoreconf

Default: no
Example:
```
use_autoreconf      yes
```

autoreconf.args

Arguments to pass to autoreconf.

Default: --install --verbose

Example:

autoreconf.args       --install --verbose --force

autoreconf.dir

Directory in which to run +${autoreconf.cmd}+.

Default: ${worksrcpath}
Example:
```
autoreconf.dir        ./src
```

use_automake

Whether or not to use automake.

Default: no
Example:
```
use_automake        yes
```

automake.env

Environment variables to pass to automake.

Default: ???

Example:

automake.env        CFLAGS=-I${prefix}/include

automake.args

Arguments to pass to automake.

Default: ???
Example:
```
automake.args       --foreign
```

automake.dir

Directory in which to run +${automake.cmd}+.

Default: ${worksrcpath}
Example:
```
automake.dir        ./src
```

use_autoconf

Whether or not to use autoconf.

Default: no
Example:
```
use_autoconf        yes
```

autoconf.env

Environmental variables to pass to autoconf.

Default: ???

Example:

autoconf.env        CFLAGS=-I${prefix}/include/gtk12

autoconf.args

Arguments to pass to autoconf.

Default: ???
Example:
```
autoconf.args       "-l src/aclocaldir"
```

autoconf.dir

Directory in which to run +${autoconf.cmd}+.

Default: ${worksrcpath}
Example:
```
autoconf.dir        src
```

5.3.8. Build Phase Keywords

The list of keywords related to the build phase.

build.cmd

Make command to run in +${worksrcdir}+. Only use it if you can’t use +build.type+.

Default: +make+
Example:
```
build.cmd           scons
```

build.type

Defines which build software is required and sets ${build.cmd} accordingly. The available options are BSD Make, GNU Make, and Xcode.

Default: default (the default Make on the current platform)
Values: defaultbsd+gnu++xcode+
Example:
```
build.type          bsd
```

build.args

Main arguments to +${build.cmd}+; optional argument modifiers pass arguments before and after the main arguments.

Default: none
Example:
```
build.args          -DNOWARN
```

The following argument modifiers are available:

+build.pre_args+, defaults to: ${build.target}
+build.post_args+, defaults to: none

Examples:

build.pre_args      -project AudioSlicer.xcode
build.post_args     CFLAGS_SYS="-DUSE_FREETYPE -DPREFER_FREETYPE"

build.target

Build target to pass to +${build.cmd}+; list modifiers add or delete items from a previous Portfile build.target keyword or the default set by MacPorts base.

Default: all

Example:

build.target        all-src

build.target-append     doc extra
build.target-delete     compat

build.env

Set environment variables for build; list modifiers add and delete items from a previous Portfile build.env keyword, or a default set by MacPorts base.

Default: none

use_parallel_build

This keyword is for specifying whether or not it is safe for a port to use multiple CPUs or multiple cores in parallel during its build phase. If use_parallel_build is not set to “no” in a given port, the option -j${build.jobs} is passed to ${build.cmd} (if ${build.cmd} is +make+ or +scons+).

Default: yes
Example:
```
use_parallel_build  no
```

build.jobs

The number of simultaneous jobs to run when parallel build is enabled. The default value is based on the variable buildmakejobs in macports.conf.

Default: If buildmakejobs is 0, the number of CPU cores in the machine, or the number of GB of physical memory plus one, whichever is less. Otherwise, the actual value of +${buildmakejobs}+.

5.3.9. Test Phase Keywords

The list of keywords related to the test phase.

test.run

Enable running test suites bundled with a port.

Default: no
Example:
```
test.run            yes
```

test.cmd

Test command to run relative to +${worksrcdir}+.

Default: ${build.cmd}
Example:
```
test.cmd            checks.sh
```

test.target

Test target to pass to +${test.cmd}+.

Default: test
Example:
```
test.target         checks
```

test.args

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

Default: none
Example:
```
test.args    -f Makefile.test
```

The following argument modifiers are available:

+test.pre_args+, defaults to: ${test.target}
+test.post_args+, defaults to: none

test.env

Set environment variables for test; list modifiers add and delete items from a previous Portfile test.env keyword, or a default set by MacPorts base.

Often DYLD_LIBRARY_PATH is set here to support testing dynamically linked libraries.

Default: none

Example:

test.env       DYLD_LIBRARY_PATH=${worksrcpath}/src/.libs

5.3.10. Destroot Phase Keywords

The list of keywords related to the destroot phase.

destroot.cmd

Install command to run relative to +${worksrcdir}+.

Default: ${build.cmd}
Example:
```
destroot.cmd        scons
```

destroot.args

Main arguments to +${destroot.cmd}+; optional argument modifiers pass arguments before and after the main arguments.

Default: none

Example:

destroot.args       BINDIR=${prefix}/bin

The following argument modifiers are available:

+destroot.pre_args+, defaults to: ${destroot.target}
+destroot.post_args+, defaults to: ${destroot.destdir}

Examples:

destroot.pre_args   -project AudioSlicer.xcode
destroot.post_args  INSTDIR=${destroot}${prefix}

destroot.target

Install target to pass to +${destroot.cmd}+; list modifiers add or delete items from a previous Portfile destroot.target keyword or the default set by MacPorts base.

Default: install

Example:

destroot.target     install install-config install-commandmode

destroot.target-append  install-plugins
destroot.target-delete  install-commandmode

destroot.destdir

Arguments passed to ${destroot.cmd} via ${destroot.post_args} to install correctly into the destroot.

Default: DESTDIR=${destroot}

Example:

destroot.destdir    prefix=${destroot}${prefix}

Note

If an application’s Makefile properly supports the DESTDIR variable, MacPorts will automatically destroot the port properly. A port must destroot properly or the port will not install correctly, upgrade, or uninstall. If not, you may need to set this variable, or even patch the application’s Makefile.

destroot.umask

Umask to use during destroot.

Default: 022
Example:
```
destroot.umask      002
```

destroot.keepdirs

A list of directories that should not be removed if empty upon destroot completion.

Default: ???

Example:

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

destroot.violate_mtree

MacPorts tests for compliance to the common directory structure in +${prefix}+. If a port is not compliant with the standard, set it to +yes+.

You can find the macports standard in MacPorts File Hierarchy or in the porthier(7) man page.

If destroot.violate_mtree is set to +yes+, the following warning is issued during the installation.

Warning: portname requests to install files outside the common directory structure!

+ This means that the port installed files outside of their normal locations in +${prefix}+. These could be files totally outside of +${prefix}+, which could cause problems on your computer, or files inside of ${prefix} that are not in a standard location. Use +port contents +portname++ to see the location for all files that were installed by a given port.

Default: no
Example:
```
destroot.violate_mtree      yes
```

Prev	Up	Next
5.2. Global Variables	Home	5.4. Dependencies