1. Introduction
2. Installing MacPorts
2.1. Install Xcode
2.2. Install MacPorts
2.3. Upgrade MacPorts
2.4. Uninstall MacPorts
2.5. 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
4.8. MacPorts' buildbot
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 & Useful Tcl Commands
5.7. StartupItems
5.8. Livecheck / Distcheck
5.9. PortGroups
5.10. PortGroup Introduction
5.11. PortGroup github
5.12. PortGroup gnustep
5.13. PortGroup golang
5.14. PortGroup haskell
5.15. PortGroup java
5.16. PortGroup perl5
5.17. PortGroup python
5.18. PortGroup ruby
5.19. PortGroup xcode
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
6.6. Tests
7. MacPorts Project
7.1. Using Trac for Tickets
7.2. Using Git and GitHub
7.3. Contributing to MacPorts
7.4. Port Update Policies
7.5. Updating Documentation
7.6. MacPorts Membership
7.7. The PortMgr Team
8. MacPorts Guide Glossary
Glossary

5.4. Dependencies

Free and open source software is highly modular, and MacPorts ports often require that other ports be installed beforehand; these prerequisites for a given port are called a port’s dependencies.

The keywords used when specifying dependencies in a Portfile are related to port install phases, and they refer to what are called library, build, fetch, extract and run dependencies. Though all of them install dependencies before a given port is installed, specifying dependencies with the correct keyword is important for proper port upgrade and uninstall behavior, or when running targets other than install. For example, you may not uninstall a port that is a library dependency for another installed port, though you may remove one that is a build dependency. Likewise, if you run the fetch target for a port, only the fetch dependencies will be installed first, so they should be all that is needed for that target.

depends_fetch
The list of dependencies to check before phases +fetch+, +checksum+, +extract+, +patch+, +configure+, +build+, +destroot+, +install+, and +package+. Fetch dependencies are needed to download the distfiles for a port, and are not needed at all once the software is installed.
depends_extract
The list of dependencies to check before phases +extract+, +patch+, +configure+, +build+, +destroot+, +install+, and +package+. Extract dependencies are needed to unpack a port’s distfiles into the work directory, and are not needed at all once the software is installed.
depends_build
The list of dependencies to check before phases +configure+, +build+, +destroot+, +install+, and +package+. Build dependencies are needed when software is being built, but not needed at all once it is installed.
depends_lib
The list of dependencies to check before phases +configure+, +build+, +destroot+, +install+, and +package+. Library dependencies are needed both at build time (for headers and libraries to link against) and at run time.
depends_test
The list of dependencies to check before phase +test+. Test dependencies are only needed when the port enables testing (i.e. +test.run yes+).
depends_run
The list of dependencies to check before phases +destroot+, +install+, and +package+. Run dependencies are needed when the software is run, but not to compile it.

5.4.1. Port and File Dependencies

There are two types of dependencies: port dependencies and file dependencies. Port dependencies can be satisfied by reference to a port (the MacPorts registry is queried), or by reference to a file (whether provided by a port or not). The most commonly-used type of dependencies in Portfiles are port dependencies, because dependencies should be provided by MacPorts ported software whenever possible, and usually only one port can provide the needed libraries and files.

But when satisfying a dependency with vendor-supplied software is preferred for special reasons, or when it is possible for more than one port to satisfy a dependency, then file dependencies may be used. An example of the former is with ubiquitous utilities like awk, grep, make or sed, where the versions in macOS are often sufficient; an example of the latter is with -devel ports—​these ports provide a different version of the same files (though only one can be activated at a time).

Port dependencies, the preferred type, are specified as shown in these examples:

depends_lib         port:rrdtool port:apache2

depends_build       port:libtool

depends_run         port:apache2 port:php5

File dependencies should only be used if one of the reasons listed above applies. There are three types: bin for programs, lib for libraries, and path for any installed file. File dependencies are specified in the form: +<type>+:<filespec>:<port>.

For bin dependencies, <filespec> is the name of a program in a bin directory like ${prefix}/bin, /usr/bin, /bin, and the associated sbin directories.

For lib dependencies, <filespec> is the name of a library (but without its extension) in a lib directory like ${prefix}/lib, /usr/lib, /lib, some Framework directories, and those found in environment variables like DYLD_LIBRARY_PATH.

For path dependencies, <filespec> is the complete absolute path to the file, or more usually, when the file is inside ${prefix}, it is specified relative to ${prefix}. Since path dependencies are the only ones which would find files only in an absolute path or a path inside ${prefix} they are - in cases when a port needs to be more restrictive - often used instead of bin and lib dependencies .

Note that the <port> specified is only installed if the specified library, binary, or file is not found. See the examples below:

depends_lib         lib:libX11.6:xorg

depends_build       bin:glibtool:libtool

depends_run         path:lib/libltdl.a:libtool