Index: head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml (revision 48467) +++ head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml (revision 48468) @@ -1,485 +1,485 @@ Slow Porting Okay, so it was not that simple, and the port required some modifications to get it to work. In this section, we will explain, step by step, how to modify it to get it to work with the ports paradigm. How Things Work First, this is the sequence of events which occurs when the user first types make in the port's directory. Having bsd.port.mk in another window while reading this really helps to understand it. - But do not worry not many people understand exactly how + But do not worry, not many people understand exactly how bsd.port.mk is working... :-) The fetch target is run. The fetch target is responsible for making sure that the tarball exists locally in DISTDIR. If fetch cannot find the required files in DISTDIR it will look up the URL MASTER_SITES, which is set in the Makefile, as well as our FTP mirrors where we put distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed. The extract target is run. It looks for the port's distribution file (typically a gzipped tarball) in DISTDIR and unpacks it into a temporary subdirectory specified by WRKDIR (defaults to work). The patch target is run. First, any patches defined in PATCHFILES are applied. Second, if any patch files named patch-* are found in PATCHDIR (defaults to the files subdirectory), they are applied at this time in alphabetical order. The configure target is run. This can do any one of many different things. If it exists, scripts/configure is run. If HAS_CONFIGURE or GNU_CONFIGURE is set, WRKSRC/configure is run. The build target is run. This is responsible for descending into the port's private working directory (WRKSRC) and building it. The stage target is run. This puts the final set of built files into a temporary directory (STAGEDIR, see ). The hierarchy of this directory mirrors that of the system on which the package will be installed. The package target is run. This creates a package using the files from the temporary directory created during the stage target and the port's pkg-plist. The install target is run. This installs the package created during the package target into the host system. The above are the default actions. In addition, define targets pre-something or post-something, or put scripts with those names, in the scripts subdirectory, and they will be run before or after the default actions are done. For example, if there is a post-extract target defined in the Makefile, and a file pre-build in the scripts subdirectory, the post-extract target will be called after the regular extraction actions, and pre-build will be executed before the default build rules are done. It is recommended to use Makefile targets if the actions are simple enough, because it will be easier for someone to figure out what kind of non-default action the port requires. The default actions are done by the do-something targets from bsd.port.mk. For example, the commands to extract a port are in the target do-extract. If the default target does not do the job right, redefine the do-something target in the Makefile. The main targets (for example, extract, configure, etc.) do nothing more than make sure all the stages up to that one are completed and call the real targets or scripts, and they are not intended to be changed. To fix the extraction, fix do-extract, but never ever change the way extract operates! Additionally, the target post-deinstall is invalid and is not run by the ports infrastructure. Now that what goes on when the user types make install is better understood, let us go through the recommended steps to create the perfect port. Getting the Original Sources Get the original sources (normally) as a compressed tarball (foo.tar.gz or foo.tar.bz2) and copy it into DISTDIR. Always use mainstream sources when and where possible. Set the variable MASTER_SITES to reflect where the original tarball resides. Shorthand definitions exist for most mainstream sites in bsd.sites.mk. Please use these sites—and the associated definitions—if at all possible, to help avoid the problem of having the same information repeated over again many times in the source base. As these sites tend to change over time, this becomes a maintenance nightmare for everyone involved. See for details. If there is no FTP/HTTP site that is well-connected to the net, or can only find sites that have irritatingly non-standard formats, put a copy on a reliable FTP or HTTP server (for example, a home page). If a convenient and reliable place to put the distfile cannot be found, we can house it ourselves on ftp.FreeBSD.org; however, this is the least-preferred solution. The distfile must be placed into ~/public_distfiles/ of someone's freefall account. Ask the person who commits the port to do this. This person will also set MASTER_SITES to LOCAL/username where username is their &os; cluster login. If the port's distfile changes all the time without any kind of version update by the author, consider putting the distfile on a home page and listing it as the first MASTER_SITES. Try to talk the port author out of doing this; it really does help to establish some kind of source code control. Hosting a specific version will prevent users from getting checksum mismatch errors, and also reduce the workload of maintainers of our FTP site. Also, if there is only one master site for the port, it is recommended to house a backup on a home page and list it as the second MASTER_SITES. If the port requires additional patches that are available on the Internet, fetch them too and put them in DISTDIR. Do not worry if they come from a site other than where the main source tarball comes, we have a way to handle these situations (see the description of PATCHFILES below). Modifying the Port Unpack a copy of the tarball in a private directory and make whatever changes are necessary to get the port to compile properly under the current version of &os;. Keep careful track of steps, as they will be needed to automate the process shortly. Everything, including the deletion, addition, or modification of files has to be doable using an automated script or patch file when the port is finished. If the port requires significant user interaction/customization to compile or install, take a look at one of Larry Wall's classic Configure scripts and perhaps do something similar. The goal of the new ports collection is to make each port as plug-and-play as possible for the end-user while using a minimum of disk space. Unless explicitly stated, patch files, scripts, and other files created and contributed to the &os; ports collection are assumed to be covered by the standard BSD copyright conditions. Patching In the preparation of the port, files that have been added or changed can be recorded with &man.diff.1; for later feeding to &man.patch.1;. Doing this with a typical file involves saving a copy of the original file before making any changes using a .orig suffix. &prompt.user; cp file file.orig After all changes have been made, cd back to the port directory. Use make makepatch to generate updated patch files in the files directory. General Rules for Patching Patch files are stored in PATCHDIR, usually files/, from where they will be automatically applied. All patches must be relative to WRKSRC. Typically WRKSRC is a subdirectory of WRKDIR, the directory where the distfile is extracted. Use make -V WRKSRC to see the actual path. The patch names are to follow these rules: Avoid having more than one patch modify the same file. For example, having both patch-foobar.c and patch-foobar.c2 making changes to ${WRKSRC}/foobar.c makes them fragile and difficult to debug. When creating names for patch files, replace each underscore (_) with two underscores (__) and each slash (/) with one underscore (_). For example, to patch a file named src/freeglut_joystick.c, name the corresponding patch patch-src_freeglut__joystick.c. Do not name patches like patch-aa or patch-ab. Always use the path and file name in patch names. Using make makepatch automatically generates the correct names. A patch may modify multiple files if the changes are related and the patch is named appropriately. For example, patch-add-missing-stdlib.h. Only use characters [-+._a-zA-Z0-9] for naming patches. In particular, do not use :: as a path separator, use _ instead. Minimize the amount of non-functional whitespace changes in patches. It is common in the Open Source world for projects to share large amounts of a code base, but obey different style and indenting rules. When taking a working piece of functionality from one project to fix similar areas in another, please be careful: the resulting patch may be full of non-functional changes. It not only increases the size of the ports repository but makes it hard to find out what exactly caused the problem and what was changed at all. If a file must be deleted, do it in the post-extract target rather than as part of the patch. Manual Patch Generation Manual patch creation is usually not necessary. Automatic patch generation as described earlier in this section is the preferred method. However, manual patching may be required occasionally. Patches are saved into files named patch-* where * indicates the pathname of the file that is patched, such as patch-Imakefile or patch-src-config.h. After the file has been modified, &man.diff.1; is used to record the differences between the original and the modified version. causes &man.diff.1; to produce unified diffs, the preferred form. &prompt.user; diff -u file.orig file > patch-pathname-file When generating patches for new, added files, is used to tell &man.diff.1; to treat the non-existent original file as if it existed but was empty: &prompt.user; diff -u -N newfile.orig newfile > patch-pathname-newfile Do not add $FreeBSD$ RCS strings in patches. When patches are added to the Subversion repository with svn add, the fbsd:nokeywords property is set to yes automatically so keywords in the patch are not modified when committed. The property can be added manually with svn propset fbsd:nokeywords yes files.... Using the recurse () option to &man.diff.1; to generate patches is fine, but please look at the resulting patches to make sure there is no unnecessary junk in there. In particular, diffs between two backup files, Makefiles when the port uses Imake or GNU configure, etc., are unnecessary and have to be deleted. If it was necessary to edit configure.in and run autoconf to regenerate configure, do not take the diffs of configure (it often grows to a few thousand lines!). Instead, define USE_AUTOTOOLS=autoconf:261 and take the diffs of configure.in. Simple Automatic Replacements Simple replacements can be performed directly from the port Makefile using the in-place mode of &man.sed.1;. This is useful when changes use the value of a variable: post-patch: @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README Quite often, software being ported uses the CR/LF convention in source files. This may cause problems with further patching, compiler warnings, or script execution (like /bin/sh^M not found.) To quickly convert all files from CR/LF to just LF, add this entry to the port Makefile: USES= dos2unix A list of specific files to convert can be given: USES= dos2unix DOS2UNIX_FILES= util.c util.h Use DOS2UNIX_REGEX to convert a group of files across subdirectories. Its argument is a &man.find.1;-compatible regular expression. More on the format is in &man.re.format.7;. This option is useful for converting all files of a given extension. For example, convert all source code files, leaving binary files intact: USES= dos2unix DOS2UNIX_REGEX= .*\.([ch]|cpp) A similar option is DOS2UNIX_GLOB, which runs find for each element listed in it. USES= dos2unix DOS2UNIX_GLOB= *.c *.cpp *.h - If there are more than one distribution file and some - other than the default need to have files converted, the base - directory for the conversions can be changed so that they are - also converted. + + The base directory for the conversion can be set. This + is useful when there are multiple distfiles and several + contain files which require line-ending conversion. USES= dos2unix DOS2UNIX_WRKSRC= ${WRKDIR} Configuring Include any additional customization commands in the configure script and save it in the scripts subdirectory. As mentioned above, it is also possible do this with Makefile targets and/or scripts with the name pre-configure or post-configure. Handling User Input If the port requires user input to build, configure, or install, set IS_INTERACTIVE in the Makefile. This will allow overnight builds to skip it. If the user sets the variable BATCH in his environment (and if the user sets the variable INTERACTIVE, then only those ports requiring interaction are built). This will save a lot of wasted time on the set of machines that continually build ports (see below). It is also recommended that if there are reasonable default answers to the questions, PACKAGE_BUILDING be used to turn off the interactive script when it is set. This will allow us to build the packages for CDROMs and FTP. Index: head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml (revision 48467) +++ head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml (revision 48468) @@ -1,1492 +1,1492 @@ Using <varname>USES</varname> Macros An Introduction to <varname>USES</varname> USES macros make it easy to declare requirements and settings for a port. They can add dependencies, change building behavior, add metadata to packages, and so on, all by selecting simple, preset values.. Each section in this chapter describes a possible value for USES, along with its possible arguments. Arguments are appeneded to the value after a colon (:). Multiple arguments are separated by commas (,). Using Multiple Values USES= bison perl Adding an Argument USES= gmake:lite Adding Multiple Arguments USES= drupal:7,theme Mixing it All Together USES= pgsql:9.3+ cpe python:2.7,build <literal>ada</literal> Possible arguments: (none), 47, 49, 5 Depends on an Ada-capable compiler, and sets CC accordingly. Defaults to a gcc 4.9 based compiler, use :47 to use the older gcc 4.7 based one and :5 to use the newer gcc 5 based one. <literal>autoreconf</literal> Possible arguments: (none), build Runs autoreconf. It encapsulates the aclocal, autoconf, autoheader, automake, autopoint, and libtoolize commands. Each command applies to ${CONFIGURE_WRKSRC}/configure.ac or its old name, ${CONFIGURE_WRKSRC}/configure.in. If configure.ac defines subdirectories with their own configure.ac using AC_CONFIG_SUBDIRS, autoreconf will recursively update those as well. The :build argument only adds build time dependencies on those tools but does not run autoreconf. <literal>blaslapack</literal> Possible arguments: (none), atlas, netlib (default), gotoblas, openblas Adds dependencies on Blas / Lapack libraries. <literal>bison</literal> Possible arguments: (none), build, run, both Uses devel/bison By default, with no arguments or with the build argument, it implies bison is a build-time dependency, run implies a run-time dependency, and both implies both run-time and build-time dependencies. <literal>charsetfix</literal> Possible arguments: (none) Prevents the port from installing charset.alias. This must be installed only by converters/libiconv. CHARSETFIX_MAKEFILEIN can be set to a path relative to WRKSRC if charset.alias is not installed by ${WRKSRC}/Makefile.in. <literal>cmake</literal> Possible arguments: (none), outsource, run Uses CMake for configuring and building. With the outsource argument, an out-of-source build will be performed. With the run argument, a run-time dependency is registered. For more information see . <literal>compiler</literal> Possible arguments: (none), c++14-lang, c++11-lang, gcc-c++11-lib, c++11-lib, c++0x, c11, openmp, nestedfct, features Determines which compiler to use based on any given wishes. Use c++14-lang if the port needs a C++14-capable compiler, gcc-c++11-lib if the port needs the g++ compiler with a C++11 library, or c++11-lib if the port needs a C++11-ready standard library. If the port needs a compiler understanding C++11, C++0X, C11, OpenMP, or nested functions, the corresponding parameters can be used. Use features to request a list of features supported by the default compiler. After including bsd.port.pre.mk the port can inspect the results using these variables: COMPILER_TYPE: the default compiler on the system, either gcc or clang ALT_COMPILER_TYPE: the alternative compiler on the system, either gcc or clang. Only set if two compilers are present in the base system. COMPILER_VERSION: the first two digits of the version of the default compiler. ALT_COMPILER_VERSION: the first two digits of the version of the alternative compiler, if present. CHOSEN_COMPILER_TYPE: the chosen compiler, either gcc or clang COMPILER_FEATURES: the features supported by the default compiler. It currently lists the C++ library. <literal>cpe</literal> Possible arguments: (none) Include Common Platform Enumeration (CPE) information in package manifest as a CPE 2.3 formatted string. See the CPE specification for details. To add CPE information to a port, follow these steps: Search for the official CPE para for the software product either by using the NVD's CPE search engine or in the official CPE dictionary (warning, very large XML file). Do not ever make up CPE data. Add cpe to USES and compare the result of make -V CPE_STR to the CPE dictionary para. Continue one step at a time until make -V CPE_STR is correct. If the product name (second field, defaults to PORTNAME) is incorrect, define CPE_PRODUCT. If the vendor name (first field, defaults to CPE_PRODUCT) is incorrect, define CPE_VENDOR. If the version field (third field, defaults to PORTVERSION) is incorrect, define CPE_VERSION. If the update field (fourth field, defaults to empty) is incorrect, define CPE_UPDATE. If it is still not correct, check Mk/Uses/cpe.mk for additional details, or contact the &a.ports-secteam;. Derive as much as possible of the CPE name from existing variables such as PORTNAME and PORTVERSION. Use variable modifiers to extract the relevant portions from these variables rather than hardcoding the name. Always run make -V CPE_STR and check the output before committing anything that changes PORTNAME or PORTVERSION or any other variable which is used to derive CPE_STR. <literal>cran</literal> Possible arguments: (none), auto-plist Uses the Comprehensive R Archive Network. Specify auto-plist to automatically generate pkg-plist. <literal>desktop-file-utils</literal> Possible arguments: (none) Uses update-desktop-database from devel/desktop-file-utils. An extra post-install step will be run without interfering with any post-install steps already in the port Makefile. A line with @desktop-file-utils will be added to the plist. <literal>desthack</literal> Possible arguments: (none) Changes the behavior of GNU configure to properly support DESTDIR in case the original software does not. <literal>display</literal> Possible arguments: (none), ARGS Set up a virtual display environment. If the environment variable DISPLAY is not set, then Xvfb is added as a build dependency, and CONFIGURE_ENV is extended with the port number of the currently running instance of Xvfb. The ARGS parameter defaults to install and controls the phase around which to start and stop the virtual display. <literal>dos2unix</literal> Possible arguments: (none) The port has files with line endings in - DOS format which need to be converted. Four + DOS format which need to be converted. Several variables can be set to control which files will be converted. The default is to convert all files, including binaries. See for examples. DOS2UNIX_REGEX: match file names based on a regular expression. DOS2UNIX_FILES: match literal file names. DOS2UNIX_GLOB: match file names based on a glob pattern. DOS2UNIX_WRKSRC: the directory from - which to start doing the conversions, defaults to + which to start the conversions. Defaults to ${WRKSRC}. <literal>drupal</literal> Possible arguments: 6, 7, module, theme Automate installation of a port that is a Drupal theme or module. Use with the version of Drupal that the port is expecting. For example, USES=drupal:6,module says that this port creates a Drupal 6 module. A Drupal 7 theme can be specified with USES=drupal:7,theme. <literal>execinfo</literal> Possible arguments: (none) Add a library dependency on devel/libexecinfo if libexecinfo.so is not present in the base system. <literal>fakeroot</literal> Possible arguments: (none) Changes some default behaviour of build systems to allow installing as a user. See for more information on fakeroot. <literal>fam</literal> Possible arguments: (none), fam, gamin Uses a File Alteration Monitor as a library dependency, either devel/fam or devel/gamin. End users can set WITH_FAM_SYSTEM to specify their preference. <literal>fmake</literal> Possible arguments: (none) Uses devel/fmake as a build-time dependency. <literal>fonts</literal> Possible arguments: (none), fc, fcfontsdir (default), fontsdir, none Adds a runtime dependency on tools needed to register fonts. Depending on the argument, add a @fc ${FONTSDIR} line, @fcfontsdir ${FONTSDIR} line, @fontsdir ${FONTSDIR} line, or no line if the argument is none, to the plist. FONTSDIR defaults to ${PREFIX}/share/fonts/${FONTNAME} and FONTNAME to ${PORTNAME}. Add FONTSDIR to PLIST_SUB and SUB_LIST <literal>fortran</literal> Possible arguments: gcc (default), ifort Uses the Fortran compiler from either GNU or Intel. <literal>fuse</literal> Possible arguments: (none) The port will depend on the FUSE library and handle the dependency on the kernel module depending on the version of &os;. <literal>gecko</literal> Possible arguments: libxul (default), firefox, seamonkey, thunderbird, build, XY, XY+ Add a dependency on different gecko based applications. If libxul is used, it is the only argument allowed. When the argument is not libxul, the firefox, seamonkey, or thunderbird arguments can be used, along with optional build and XY/XY+ version arguments. <literal>gettext</literal> Possible arguments: (none) Deprecated. Will include both gettext-runtime and gettext-tools. <literal>gettext-runtime</literal> Possible arguments: (none), lib (default), build, run Uses devel/gettext-runtime. By default, with no arguments or with the lib argument, implies a library dependency on libintl.so. build and run implies, respectively a build-time and a run-time dependency on gettext. <literal>gettext-tools</literal> Possible arguments: (none), build (default), run Uses devel/gettext-tools. By default, with no argument, or with the build argument, a build time dependency on msgfmt is registered. With the run argument, a run-time dependency is registered. <literal>ghostscript</literal> Possible arguments: X, build, run, nox11 A specific version X can be used. Possible versions are 7, 8, 9 (default), and agpl. nox11 indicates that the -nox11 version of the port is required. build and run add build- and run-time dependencies on Ghostscript. The default is both build- and run-time dependencies. <literal>gmake</literal> Possible arguments: (none), lite Uses devel/gmake, or devel/gmake-lite if the lite argument is used, as a build-time dependency and sets up the environment to use gmake as the default make for the build. <literal>gperf</literal> Possible arguments: (none) Add a buildtime dependency on devel/gperf if gperf is not present in the base system. <literal>gssapi</literal> Possible arguments: (none), base (default), heimdal, mit, flags, bootstrap Handle dependencies needed by consumers of the GSS-API. Only libraries that provide the Kerberos mechanism are available. By default, or set to base, the GSS-API library from the base system is used. Can also be set to heimdal to use security/heimdal, or mit to use security/krb5. When the local Kerberos installation is not in LOCALBASE, set HEIMDAL_HOME (for heimdal) or KRB5_HOME (for krb5) to the location of the Kerberos installation. These variables are exported for the ports to use: GSSAPIBASEDIR GSSAPICPPFLAGS GSSAPIINCDIR GSSAPILDFLAGS GSSAPILIBDIR GSSAPILIBS GSSAPI_CONFIGURE_ARGS The flags option can be given alongside base, heimdal, or mit to automatically add GSSAPICPPFLAGS, GSSAPILDFLAGS, and GSSAPILIBS to CFLAGS, LDFLAGS, and LDADD, respectively. For example, use base,flags. The bootstrap option is a special prefix only for use by security/krb5 and security/heimdal. For example, use bootstrap,mit. Typical Use OPTIONS_SINGLE= GSSAPI OPTIONS_SINGLE_GSSAPI= GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE GSSAPI_BASE_USES= gssapi GSSAPI_BASE_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS} GSSAPI_HEIMDAL_USES= gssapi:heimdal GSSAPI_HEIMDAL_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS} GSSAPI_MIT_USES= gssapi:mit GSSAPI_MIT_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS} GSSAPI_NONE_CONFIGURE_ON= --without-gssapi <literal>horde</literal> Possible arguments: (none) Add buildtime and runtime dependencies on devel/pear-channel-horde. Other Horde dependencies can be added with USE_HORDE_BUILD and USE_HORDE_RUN. See for more information. <literal>iconv</literal> Possible arguments: (none), lib, build, patch, translit, wchar_t Uses iconv functions, either from the port converters/libiconv as a build-time and run-time dependency, or from the base system on 10-CURRENT after a native iconv was committed in 254273. By default, with no arguments or with the lib argument, implies iconv with build-time and run-time dependencies. build implies a build-time dependency, and patch implies a patch-time dependency. If the port uses the WCHAR_T or //TRANSLIT iconv extensions, add the relevant arguments so that the correct iconv is used. For more information see . <literal>imake</literal> Possible arguments: (none), env, notall, noman Add devel/imake as a build-time dependency and run xmkmf -a during the configure stage. If the env argument is given, the configure target is not set. If the flag is a problem for the port, add the notall argument. If xmkmf does not generate a install.man target, add the noman argument. <literal>kmod</literal> Possible arguments: (none) Fills in the boilerplate for kernel module ports, currently: Add kld to CATEGORIES. Set SSP_UNSAFE. Set IGNORE if the kernel sources are not found in SRC_BASE. Define KMODDIR to /boot/modules by default, add it to PLIST_SUB and MAKE_ENV, and create it upon installation. If KMODDIR is set to /boot/kernel, it will be rewritten to /boot/modules. This prevents breaking packages when upgrading the kernel due to /boot/kernel being renamed to /boot/kernel.old in the process. Handle cross-referencing kernel modules upon installation and deinstallation, using @kld. <literal>lha</literal> Possible arguments: (none) Set EXTRACT_SUFX to .lzh <literal>libarchive</literal> Possible arguments: (none) Registers a dependency on archivers/libarchive. Any ports depending on libarchive must include USES=libarchive. <literal>libedit</literal> Possible arguments: (none) Registers a dependency on devel/libedit. Any ports depending on libedit must include USES=libedit. <literal>libtool</literal> Possible arguments: (none), keepla, build Patches libtool scripts. This must be added to all ports that use libtool. The keepla argument can be used to keep .la files. Some ports do not ship with their own copy of libtool and need a build time dependency on devel/libtool, use the :build argument to add such dependency. <literal>localbase</literal> Possible arguments: (none) Ensures that libraries from dependencies in LOCALBASE are used instead of the ones from the base system. Ports that depend on libraries that are also present in the base system should use this. It is also used internally by a few other USES. <literal>lua</literal> Possible arguments: (none), XY+, XY, build, run Adds a dependency on Lua. By default this is a library dependency, unless overridden by the build or run option. The default version is 5.2, unless set by the XY parameter (for example, 51 or 52+). <literal>makeinfo</literal> Possible arguments: (none) Add a build-time dependency on makeinfo if it is not present in the base system. <literal>makeself</literal> Possible arguments: (none) Indicates that the distribution files are makeself archives and sets the appropriate dependencies. <literal>metaport</literal> Possible arguments: (none) Sets the following variables to make it easier to create a metaport: MASTER_SITES, DISTFILES, EXTRACT_ONLY, NO_BUILD, NO_INSTALL, NO_MTREE, NO_ARCH. <literal>mono</literal> Possible arguments: (none) Adds a dependency on the Mono (currently only C#) framework by setting the appropriate dependencies. <literal>motif</literal> Possible arguments: (none) Uses x11-toolkits/open-motif as a library dependency. End users can set WANT_LESSTIF for the dependency to be on x11-toolkits/lesstif instead of x11-toolkits/open-motif. <literal>ncurses</literal> Possible arguments: (none), base, port Uses ncurses, and causes some useful variables to be set. <literal>ninja</literal> Possible arguments: (none) Uses ninja to build the port. End users can set NINJA_VERBOSE for verbose output. <literal>objc</literal> Possible arguments: (none) Add objective C dependencies (compiler, runtime library) if the base system does not support it. <literal>openal</literal> Possible arguments: al, soft (default), si, alut Uses OpenAL. The backend can be specified, with the software implementation as the default. The user can specify a preferred backend with WANT_OPENAL. Valid values for this knob are soft (default) and si. <literal>pathfix</literal> Possible arguments: (none) Look for Makefile.in and configure in the port's associated sources and fix common paths to make sure they respect the &os; hierarchy. If the port uses automake, set PATHFIX_MAKEFILEIN to Makefile.am if needed. <literal>pear</literal> Possible arguments: (none) Adds a dependency on devel/pear. It will setup default behavior for software using the PHP Extension and Application Repository. See for more information. <literal>perl5</literal> Possible arguments: (none) Depends on Perl. These variables can be set: PERL_VERSION: Full version of Perl to use, or the default if not set PERL_ARCH: Directory name of architecture dependent libraries, defaults to mach PERL_PORT: Name of the Perl port to be installed, the default is derived from PERL_VERSION SITE_PERL: Directory name for site specific Perl packages USE_PERL5: Phases in which to use Perl, can be extract, patch, build, install, or run. It can also be configure, modbuild, or modbuildtiny when Makefile.PL, Build.PL, or the Module::Build::Tiny flavor of Build.PL is required. It defaults to build run. <literal>pgsql</literal> Possible arguments: (none), X.Y, X.Y+, X.Y- Provide support for PostgreSQL. Maintainer can set version required. Minimum and maximum versions can be specified; for example, 9.0-, 8.4+. Add PostgreSQL component dependency, using WANT_PGSQL=component[:target]. for example, WANT_PGSQL=server:configure pltcl plperl For the full list use make -V _USE_PGSQL_DEP. <literal>pkgconfig</literal> Possible arguments: (none), build (default), run, both Uses devel/pkgconf. With no arguments or with the build argument, it implies pkg-config as a build-time dependency. run implies a run-time dependency and both implies both run-time and build-time dependencies. <literal>pure</literal> Possible arguments: (none), ffi Uses lang/pure. Largely used for building related pure ports. With the ffi argument, it implies devel/pure-ffi as a run-time dependency. <literal>python</literal> Possible arguments: (none), X.Y, X.Y+, -X.Y, X.Y-Z.A, build, run Uses Python. A supported version or version range can be specified. If Python is only needed at build or run time, it can be set as a build or run dependency with build or run. See for more information. <literal>qmail</literal> Possible arguments: (none), build, run, both, vars Uses mail/qmail. With the build argument, it implies qmail as a build-time dependency. run implies a run-time dependency. Using no argument or the both argument implies both run-time and build-time dependencies. vars will only set QMAIL variables for the port to use. <literal>qmake</literal> Possible arguments: (none), norecursive, outsource Uses QMake for configuring. For more information see . <literal>readline</literal> Possible arguments: (none), port Uses readline as a library dependency, and sets CPPFLAGS and LDFLAGS as necessary. If the port argument is used or if readline is not present in the base system, add a dependency on devel/readline <literal>scons</literal> Possible arguments: (none) Provide support for the use of devel/scons <literal>shared-mime-info</literal> Possible arguments: (none) Uses update-mime-database from misc/shared-mime-info. This uses will automatically add a post-install step in such a way that the port itself still can specify there own post-install step if needed. It also add an @shared-mime-info para to the plist. <literal>shebangfix</literal> Possible arguments: (none) A lot of software uses incorrect locations for script interpreters, most notably /usr/bin/perl and /bin/bash. The shebagngfix macro fixes shebang lines in scripts listed in SHEBANG_FILES. The shebangfix macro is run from ${WRKSRC}, so it can contain paths that are relative to ${WRKSRC}. It can also deal with absolute paths if files outside of ${WRKSRC} require patching. For example: USES= shebangfix SHEBANG_FILES= scripts/foobar.pl scripts/*.sh Currently Bash, Java, Ksh, Lua, Perl, PHP, Python, Ruby, Tcl, and Tk are supported by default. To support another interpreter, set SHEBANG_LANG, interp_OLD_CMD and interp_CMD. For example: SHEBANG_LANG= lua lua_OLD_CMD= /usr/bin/lua lua_CMD= ${LOCALBASE}/bin/lua interp_OLD_CMD will contain multiple values. Any entry with spaces must be quoted. For example, if it was not already defined, the Ksh entry could be defined as: SHEBANG_LANG= ksh ksh_OLD_CMD= "/usr/bin/env ksh" /bin/ksh /usr/bin/ksh ksh_CMD= ${LOCALBASE}/bin/ksh Some software uses strange locations for an interpreter. For example, an application might expect Python to be located in /opt/bin/python2.7. The strange path to be replaced can be declared in the port Makefile: python_OLD_CMD= /opt/bin/python2.7 The fixing of shebangs is done during the patch phase. If scripts are created with incorrect shebangs during the build phase, the build process (for examples, the configure script, or the Makefiles) must be patched to generate the right shebangs. Correct paths for supported interpreters are available in interp_CMD. <literal>tar</literal> Possible arguments: (none), Z, bz2, bzip2, lzma, tbz, tbz2, tgz, txz, xz Set EXTRACT_SUFX to .tar, .tar.Z, .tar.bz2, .tar.bz2, .tar.lzma, .tbz, .tbz2, .tgz, .txz or .tar.xz respectively. <literal>tcl</literal> Possible arguments: PORT Add a dependency on Tcl. The PORT parameter can be either tcl or tk. Either a version or wrapper dependency can be appended using PORT:version or PORT:wrapper. The version can be empty, one or more exact version numbers (currently 84, 85, or 86), or a minimal version number (currently 84+, 85+ or 86+). A build- or run-time only dependency can be specified using PORT,build or PORT,run. After including bsd.port.pre.mk the port can inspect the results using these variables: TCL_VER: chosen major.minor version of Tcl TCLSH: full path of the Tcl interpreter TCL_LIBDIR: path of the Tcl libraries TCL_INCLUDEDIR: path of the Tcl C header files TK_VER: chosen major.minor version of Tk WISH: full path of the Tk interpreter TK_LIBDIR: path of the Tk libraries TK_INCLUDEDIR: path of the Tk C header files <literal>terminfo</literal> Possible arguments: (none) Adds @terminfo to the plist. Use when the port installs *.terminfo files in ${PREFIX}/share/misc. <literal>tk</literal> Same as arguments for tcl Small wrapper when using both Tcl and Tk. The same variables are returned as when using Tcl. <literal>twisted</literal> Possible arguments: (none), ARGS Add a dependency on twistedCore. The list of required components can be specified as a value of this variable. ARGS can be one of: build: add twistedCore or any specified component as build dependency. run: add twistedCore or any specified component as run dependency. Besides build and run, one or more other supported twisted components can be specified. Supported values are listed in Uses/twisted.mk. <literal>uidfix</literal> Possible arguments: (none) Changes some default behavior (mostly variables) of the build system to allow installing this port as a normal user. Try this in the port before adding NEED_ROOT=yes <literal>uniquefiles</literal> Possible arguments: (none), dirs Make files or directories 'unique', by adding a prefix or suffix. If the dirs argument is used, the port needs a prefix (a only a prefix) based on UNIQUE_PREFIX for standard directories DOCSDIR, EXAMPLESDIR, DATADIR, WWWDIR, ETCDIR. These variables are available for ports: UNIQUE_PREFIX: The prefix to be used for directories and files. Default: ${PKGNAMEPREFIX}. UNIQUE_PREFIX_FILES: A list of files that need to be prefixed. Default: empty. UNIQUE_SUFFIX: The suffix to be used for files. Default: ${PKGNAMESUFFIX}. UNIQUE_SUFFIX_FILES: A list of files that need to be suffixed. Default: empty. <literal>webplugin</literal> Possible arguments: (none), ARGS Automatically create and remove symbolic links for each application that supports the webplugin framework. ARGS can be one of: gecko: support plug-ins based on Gecko native: support plug-ins for Gecko, Opera, and WebKit-GTK linux: support Linux plug-ins all (default, implicit): support all plug-in types (individual entries): support only the browsers listed These variables can be adjusted: WEBPLUGIN_FILES: No default, must be set manually. The plug-in files to install. WEBPLUGIN_DIR: The directory to install the plug-in files to, default PREFIX/lib/browser_plugins/WEBPLUGIN_NAME. Set this if the port installs plug-in files outside of the default directory to prevent broken symbolic links. WEBPLUGIN_NAME: The final directory to install the plug-in files into, default PKGBASE. <literal>xfce</literal> Possible arguments: (none), gtk3 Provide support for Xfce related ports. See for details. The gtk3 argument specifies that the port requires GTK3 support. It adds additional features provided by some core components, for example, x11/libxfce4menu and x11-wm/xfce4-panel. <literal>zip</literal> Possible arguments: (none), infozip Indicates that the distribution files use the ZIP compression algorithm. For files using the InfoZip algorithm the infozip argument must be passed to set the appropriate dependencies. <literal>zope</literal> Possible arguments: (none) Uses www/zope. Mostly used for building zope related ports. ZOPE_VERSION can be used by a port to indicate that a specific version of zope shall be used.