PortGroups are simply include files for portfiles. They can define as much or as little as a portgroup author feels is necessary to provide a set of definitions or behaviors common to a group of portfiles, in order that those portfiles can be expressed as simply as possible with minimum redundancy.
See the following folder for PortGroup definitions:
${prefix}/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/group/
A sample listing follows:
%%ls -1 /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/group/
archcheck-1.0.tcl cmake-1.0.tcl crossbinutils-1.0.tcl gnustep-1.0.tcl haskell-1.0.tcl hocbinding-1.0.tcl hunspelldict-1.0.tcl kde4-1.0.tcl kde4-1.1.tcl . . .
The requirements of a minimum portfile using a portgroup varies by portgroup. The sections below devoted to each portgroup (or, for portgroups not documented there yet, the comments in the header of the portgroup file itself) should provide guidance on how each portgroup is used. Prospective MacPorts developers are also encouraged to examine existing portfiles that use these portgroups.
PortGroup gnustep allows for efficient porting of GNUstep-based open source software using the GNU objective-C runtime that defines options for the configuration, build, and destroot phases, and also defines some values for GNUstep-based software. A minimum Portfile using the gnustep PortGroup class need only define the fetch and the checksum phases.
Portfiles using the gnustep PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords.
An associative array which specifies the sub-directories relative to ${worksrcpath} and the SHARED_LD_POSTFLAGS variables to be added to GNUmakefile.preamble in those sub-directories. This helps making the patching process easier on Darwin.
Type: optional
Default: none
Example:
platform darwin {
array set gnustep.post_flags {
BundleSubDir "-lfoo -lbar"
}
}Define the gcc compiler to use when compiling a port.
Type: optional
Default: gcc-mp-4.2
Example:
gnustep.cc gcc-mp-4.3
Many GNUstep packages include a Documentation sub-directory that is not built by default. Enabling this variant builds and installs the included documentation.
Type: optional
Example:
%%port install gnustep-gui +with_docs
PortGroup gnustep supports both the traditional gnustep file layout and the new fhs file layout. However, a given ported application does not necessarily support both. The Portfiles have access to many procedures to handle these two layouts:
Sets GNUSTEP_MAKEFILES according to the FilesystemLayout
Sets DYLD_LIBRARY_PATH and PATH for the gnustep FilesystemLayout
Returns true (1) if current file layout is gnustep
Sets GNUSTEP_SYSTEM_LIBRARY according to the FilesystemLayout
Sets GNUSTEP_LOCAL_LIBRARY according to the FilesystemLayout
Portfiles using PortGroup gnustep do not need to define the following variables:
Default: gnustep
Default: http://www.gnustep.org/
Default: gnustep:core
Default: gnustep-core
Default: no
Default: DYLD_LIBRARY_PATH PATH
Default: CC=gcc-mp-4.2 GNUSTEP_MAKEFILES
Default: gnu
Default: DYLD_LIBRARY_PATH PATH
Default: messages=yes
Default: DYLD_LIBRARY_PATH PATH
Default: messages=yes
PortGroup haskell simplifies the addition of Haskell packages.
Portfiles using the haskell PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords.
This keyword sets a number of port variables.
Type: required
Synopsis: the first argument is the package name, as called by hackageDB; the second is the version number
Example:
haskell.setup digest 0.0.0.2
Portfiles using PortGroup haskell do not need to define the following variables:
Default: hs-[string tolower ${package}]
Default: ${version} (from haskell.setup)
Default: devel haskell
Default: http://hackage.haskell.org
Default: ${homepage}/packages/archive/${package}/${version}
Default: ${package}-${version}
Default: ghc
Default: proper setup to run these phases
Default: creates and installs (into destroot) the register.sh and unregister.sh scripts
Default: runs the register.sh scripts
Default: runs livecheck against the package's information page
PortGroup perl5 allows for efficient porting of perl modules and other perl open source software.
Portfiles using the perl5 PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords.
This keyword sets the ${distfile} and ${version}.
Type: required
Example:
perl5.setup Net-Telnet 3.03
Portfiles using PortGroup perl5 do not need to define the following variables:
Default: perl
Default: http://search.cpan.org/dist/${distname}
Default: perl5.8
Default: no
When the perl5 PortGroup is declared within a Portfile, the following variables are provided during port install.
The MacPorts Perl version.
The Perl binary path (i.e.,
${prefix}/bin/perl).
Path to the Perl vendor directory.
Path to the Perl architecture-dependent modules directory.
PortGroup python allows for efficient porting of python-based open source software.
A number of python-version-specific PortGroups also exist, such as python27 and python32. These should not be used for new development, and ports using them should be migrated to the unified python PortGroup.
Portfiles using the python PortGroup allow for port authors to set the following keywords in addition to the general Portfile keywords.
Defines the python versions supported by this port. If the
port name starts with “py-”, then a subport will be defined for each
version in the list. For example, if a port named “py-foo” declares
python.versions 26 27, subports “py26-foo” and “py27-foo” will be
created, and will depend on python26 and python27 respectively.
If the port name does not start with “py-”, it is interpreted
as an application written in python rather than a python module. In
this case, no subports are defined, and python.versions defaults to
the value of python.default_version, which must be set. For example,
if a port named “mercurial” sets python.default_version 27, then
python.versions will automatically be set to “27”, and a dependency
on python27 will be added.
Type: required for modules, optional for apps
Example:
python.versions 25 26 27
For modules (i.e. name starts with “py-”), this sets the
subport that will be installed if the user asks to install “py-foo”
rather than e.g. “py26-foo” or “py27-foo”. If not explicitly set, a
reasonable default is chosen from the list in python.versions.
For apps (i.e. name does not start with “py-”), this chooses which version of python to use, and must be set. It can be changed in variants if desired.
Type: required for apps, optional for modules
Example:
python.default_version 32
When “yes” (the default), tells the PortGroup to automatically
link any executable binaries installed in the bin/ directory within
the framework into
${prefix}/bin.
Type: optional
Example:
python.link_binaries no
Suffix to add the the names of the links created in
${prefix}/bin when ${python.link_binaries}
is enabled. Can be cleared if no suffix is desired.
Type: optional
Default: -${python.branch}
When yes (the default), the PortGroup will automatically
try to pass the correct arch-specific flags during build time
(via the standard CFLAGS, LDFLAGS, etc environment variables).
Set this to “no” and set up those variables in build.env manually
if the default does not work.
Type: optional
Example:
python.add_archflags no
When the python PortGroup is declared within a Portfile, the following variables are provided.
The python version in use in the current subport. This will be
one of the versions listed in python.versions.
The python version in use in the current subport, in normal
dotted notation. For example, if python.version is “26”,
python.branch will be “2.6”.
The prefix in which the current python version is installed.
For framework builds, this is ${frameworks_dir}/Python.framework/Versions/${python.branch},
whereas for non-framework builds, it is the same as ${prefix}.
The path to the MacPorts Python executable.
The Python dynamic library path, i.e.
${python.prefix}/Python (framework builds) or
${prefix}/lib/libpython2.4.dylib (python24).
The path to python's lib directory, i.e.
${python.prefix}/lib/python${python.branch}.
Path to the Python include directory.
Path to the Python site-packages directory. (i.e.,
${python.prefix}/lib/python${python.branch}/site-packages).
Portfiles using PortGroup python do not need to define the following variables:
Default: python
Default: port:python${python.version}
Default: no
Default: ${python.bin} setup.py --no-user-cfg
Default: build
Default: ${python.bin} setup.py --no-user-cfg
Default: --prefix=${python.prefix} --root=${destroot}
Default: creates directory
${destroot}${prefix}/share/doc/${subport}/examples.
PortGroup ruby allows for efficient porting of ruby-based open source software.
When the ruby PortGroup is declared within a Portfile, the following variables are provided during port install.
The MacPorts Ruby version.
The Ruby binary location.
Path to the Ruby vendorlibdir directory (i.e.,
${prefix}/lib/ruby/vendor_ruby/${ruby.version})
The name for the Ruby architecture-dependent directory name
(i.e., i686-darwin8.10.1).
Path to the Ruby vendor archdir (i.e.,
${ruby.lib}/${ruby.arch}).
PortGroup xcode allows for efficient porting of
Xcode-based opensource software. A minimum Portfile for PortGroup
xcode uses defaults for the configuration, build, and destroot
phases. It also defines some values for Xcode-based software.
Using PortGroup xcode is a way to make your port able to
tolerate Xcode version updates because the PortGroup is tested against all
supported Mac OS X and Xcode versions.
Portfiles using PortGroup xcode allow for port authors
to set the following keywords in addition to the general Portfile
keywords.
The path relative to ${build.dir} and
${destroot.dir} of the Xcode project. If unset,
Xcode Tools should be able to determine it automatically. It usually
succeeds if there is only a single project in the directory.
Type: optional
Default: none
Example:
xcode.project ${name}.xcodeProject configuration/buildstyle to use.
Type: optional
Default: Deployment
Example:
xcode.configuration Main
If present, it overrides build.target and
destroot.target.
Type: optional
Default: none
Example:
xcode.target ${name}Additional settings passed to the xcode build tool during the build phase. These settings should be in the X=Y form.
Type: optional
Default: none
Example:
xcode.build.settings FRAMEWORK_SEARCH_PATHS=${prefix}/Library/FrameworksType of project that will be installed. This tells the xcode
PortGroup how to destroot the project. Correct values are
application and framework.
Type: optional
Default: application
Example:
xcode.destroot.type framework
Where to install the build product.
Type: optional
Default: ${frameworks_dir}
or ${applications_dir} depending on
xcode.destroot.type.
Additional settings passed to the xcode build tool during the destroot phase. These settings should be in the X=Y form.
Type: optional
Default: none
Example:
xcode.destroot.settings SKIP_INSTALL=NO
Settings passed to the xcode build tool when the +universal variant is selected. These settings should be in the X=Y form.
Type: optional
Default: ARCHS="${universal_archs}"
MACOSX_DEPLOYMENT_TARGET=${universal_target}
SDK to use when the +universal variant is selected. The argument may be an absolute path to an SDK, or the canonical name of an SDK.
Type: optional
Default: ${universal_sysroot}
Portfiles using the xcode PortGroup do not need to define the following variables:
Default: aqua
Default: macosx
Default: no
The following Portfile phase keywords affect the xcode PortGroup in a unique way. In most cases, you will not need to set any of these keywords in the Portfile. See portfile-phase(7)
Default: ${xcodebuildcmd}.
Default: ""
This variable will be ignored if
xcode.target is set.
Default: build
Default: ${xcodebuildcmd}
Default: ""
This variable will be ignored if
xcode.target is set.