From 5dd073a3cb450a86f0ad00b1a198e07a2efc4e16 Mon Sep 17 00:00:00 2001 From: Warren Block Date: Sun, 16 Feb 2014 03:25:22 +0000 Subject: [PATCH] Whitespace-only fixes, translators please ignore. --- .../porters-handbook/special/chapter.xml | 8072 ++++++++--------- 1 file changed, 4034 insertions(+), 4038 deletions(-) diff --git a/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml b/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml index 6493ca6d20..f49fed130e 100644 --- a/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml +++ b/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml @@ -4,855 +4,856 @@ $FreeBSD$ --> - + - Special Considerations + Special Considerations - There are some more things you have to take into account - when you create a port. This section explains the most common - of those. + There are some more things you have to take into account + when you create a port. This section explains the most common + of those. - - Staging + + Staging - bsd.port.mk expects ports to work - with a stage directory. This means that a port - should not install files directly to the regular destination - directories (that is, under PREFIX, for - example) but instead into a separate directory from which the - package is then built. In many cases, this does not require - root privileges, making it possible to build packages as an - unprivileged user. With staging, the port is built and - installed into the stage directory, - STAGEDIR. A package is created from the - stage directory and then installed on the system. Automake - tools refer to this concept as DESTDIR, but - in &os;, DESTDIR has a different meaning - (see ). + bsd.port.mk expects ports to work + with a stage directory. This means that a port + should not install files directly to the regular destination + directories (that is, under PREFIX, for + example) but instead into a separate directory from which the + package is then built. In many cases, this does not require + root privileges, making it possible to build packages as an + unprivileged user. With staging, the port is built and + installed into the stage directory, + STAGEDIR. A package is created from the + stage directory and then installed on the system. Automake + tools refer to this concept as DESTDIR, but + in &os;, DESTDIR has a different meaning + (see ). - When a port still requires system-wide privileges in order - to run the package target, this - line must be added to the - Makefile: + When a port still requires system-wide privileges in order + to run the package target, this + line must be added to the + Makefile: - NEED_ROOT= yes + NEED_ROOT= yes - Meta ports, or ports that do not install files themselves - but only depend on other ports, should avoid needlessly - extracting the &man.mtree.8; to the stage directory. This is - the basic directory layout of the package, and these empty - directories will be seens as orphans. To prevent - &man.mtree.8; extraction, add this line: + Meta ports, or ports that do not install files themselves + but only depend on other ports, should avoid needlessly + extracting the &man.mtree.8; to the stage directory. This is + the basic directory layout of the package, and these empty + directories will be seens as orphans. To prevent + &man.mtree.8; extraction, add this line: - NO_MTREE= yes + NO_MTREE= yes - Staging is enabled by prepending the - STAGEDIR variable to paths used in the - pre-install, - do-install, and - post-install targets (see the - examples through the book). Typically, this includes - PREFIX, ETCDIR, - DATADIR, EXAMPLESDIR, - MANPREFIX, DOCSDIR, and - so on. Directories should be created as part of the - post-install target. Avoid using - absolute paths whenever possible. + Staging is enabled by prepending the + STAGEDIR variable to paths used in the + pre-install, + do-install, and + post-install targets (see the + examples through the book). Typically, this includes + PREFIX, ETCDIR, + DATADIR, EXAMPLESDIR, + MANPREFIX, DOCSDIR, and + so on. Directories should be created as part of the + post-install target. Avoid using + absolute paths whenever possible. - When creating a symlink, STAGEDIR - should be prepended to the target path only. For - example: + When creating a symlink, STAGEDIR + should be prepended to the target path only. For + example: - ${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so + ${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so - The source path - ${PREFIX}/lib/libfoo.so.42 looks fine but - could, in fact, be incorrect. Absolute paths can point to a - wrong location, like when a remote file system has been - mounted with NFS under a non-root mount - point. Relative paths are less fragile, and often much - shorter. + The source path + ${PREFIX}/lib/libfoo.so.42 looks fine but + could, in fact, be incorrect. Absolute paths can point to a + wrong location, like when a remote file system has been + mounted with NFS under a non-root mount + point. Relative paths are less fragile, and often much + shorter. - Ports that install kernel modules must prepend the - STAGEDIR variable to - their destination, by default - /boot/modules. - + Ports that install kernel modules must prepend the + STAGEDIR variable to + their destination, by default + /boot/modules. + - - Shared Libraries + + Shared Libraries - If your port installs one or more shared libraries, define - a USE_LDCONFIG make variable, which will - instruct a bsd.port.mk to run - ${LDCONFIG} -m on the directory - where the new library is installed (usually - PREFIX/lib) during - post-install target to register it - into the shared library cache. This variable, when defined, - will also facilitate addition of an appropriate - @exec /sbin/ldconfig -m and - @unexec /sbin/ldconfig -R pair into your - pkg-plist file, so that a user who - installed the package can start using the shared library - immediately and de-installation will not cause the system to - still believe the library is there. + If your port installs one or more shared libraries, define + a USE_LDCONFIG make variable, which will + instruct a bsd.port.mk to run + ${LDCONFIG} -m on the directory + where the new library is installed (usually + PREFIX/lib) during + post-install target to register it + into the shared library cache. This variable, when defined, + will also facilitate addition of an appropriate + @exec /sbin/ldconfig -m and + @unexec /sbin/ldconfig -R pair into your + pkg-plist file, so that a user who + installed the package can start using the shared library + immediately and de-installation will not cause the system to + still believe the library is there. - USE_LDCONFIG= yes + USE_LDCONFIG= yes - If you need, you can override the default directory by - setting the USE_LDCONFIG value to a list of - directories into which shared libraries are to be installed. - For example if your port installs shared libraries into - PREFIX/lib/foo and - PREFIX/lib/bar - directories you could use the following in your - Makefile: + If you need, you can override the default directory by + setting the USE_LDCONFIG value to a list of + directories into which shared libraries are to be installed. + For example if your port installs shared libraries into + PREFIX/lib/foo and + PREFIX/lib/bar + directories you could use the following in your + Makefile: - USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar + USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar - Please double-check, often this is not necessary at all or - can be avoided through -rpath or setting - LD_RUN_PATH during linking (see - lang/moscow_ml for an - example), or through a shell-wrapper which sets - LD_LIBRARY_PATH before invoking the binary, - like www/seamonkey - does. + Please double-check, often this is not necessary at all or + can be avoided through -rpath or setting + LD_RUN_PATH during linking (see + lang/moscow_ml for an + example), or through a shell-wrapper which sets + LD_LIBRARY_PATH before invoking the binary, + like www/seamonkey + does. - When installing 32-bit libraries on 64-bit system, use - USE_LDCONFIG32 instead. + When installing 32-bit libraries on 64-bit system, use + USE_LDCONFIG32 instead. - Try to keep shared library version numbers in the - libfoo.so.0 format. Our runtime linker - only cares for the major (first) number. + Try to keep shared library version numbers in the + libfoo.so.0 format. Our runtime linker + only cares for the major (first) number. - When the major library version number increments in the - update to the new port version, all other ports that link to - the affected library should have their - PORTREVISION incremented, to force - recompilation with the new library version. - + When the major library version number increments in the + update to the new port version, all other ports that link to + the affected library should have their + PORTREVISION incremented, to force + recompilation with the new library version. + - - Ports with Distribution Restrictions or Legal - Concerns + + Ports with Distribution Restrictions or Legal + Concerns - Licenses vary, and some of them place restrictions on how - the application can be packaged, whether it can be sold for - profit, and so on. + Licenses vary, and some of them place restrictions on how + the application can be packaged, whether it can be sold for + profit, and so on. - - It is your responsibility as a porter to read the - licensing terms of the software and make sure that the - &os; project will not be held accountable for violating - them by redistributing the source or compiled binaries - either via FTP/HTTP or CD-ROM. If in doubt, please contact - the &a.ports;. - + + It is your responsibility as a porter to read the + licensing terms of the software and make sure that the + &os; project will not be held accountable for violating + them by redistributing the source or compiled binaries + either via FTP/HTTP or CD-ROM. If in doubt, please contact + the &a.ports;. + - In situations like this, the variables described in the - following sections can be set. + In situations like this, the variables described in the + following sections can be set. - - <varname>NO_PACKAGE</varname> + + <varname>NO_PACKAGE</varname> - This variable indicates that we may not generate a - binary package of the application. For instance, the - license may disallow binary redistribution, or it may - prohibit distribution of packages created from patched - sources. + This variable indicates that we may not generate a + binary package of the application. For instance, the + license may disallow binary redistribution, or it may + prohibit distribution of packages created from patched + sources. - However, the port's DISTFILES may be - freely mirrored on FTP/HTTP. They may also be distributed - on a CD-ROM (or similar media) unless - NO_CDROM is set as well. + However, the port's DISTFILES may be + freely mirrored on FTP/HTTP. They may also be distributed + on a CD-ROM (or similar media) unless + NO_CDROM is set as well. - NO_PACKAGE should also be used if the - binary package is not generally useful, and the application - should always be compiled from the source code. For - example, if the application has configuration information - that is site specific hard coded in to it at compile time, - set NO_PACKAGE. + NO_PACKAGE should also be used if the + binary package is not generally useful, and the application + should always be compiled from the source code. For + example, if the application has configuration information + that is site specific hard coded in to it at compile time, + set NO_PACKAGE. - NO_PACKAGE should be set to a string - describing the reason why the package should not be - generated. - + NO_PACKAGE should be set to a string + describing the reason why the package should not be + generated. + - - <varname>NO_CDROM</varname> + + <varname>NO_CDROM</varname> - This variable alone indicates that, although we are - allowed to generate binary packages, we may put neither - those packages nor the port's DISTFILES - onto a CD-ROM (or similar media) for resale. However, the - binary packages and the port's DISTFILES - will still be available via FTP/HTTP. + This variable alone indicates that, although we are + allowed to generate binary packages, we may put neither + those packages nor the port's DISTFILES + onto a CD-ROM (or similar media) for resale. However, the + binary packages and the port's DISTFILES + will still be available via FTP/HTTP. - If this variable is set along with - NO_PACKAGE, then only the port's - DISTFILES will be available, and only via - FTP/HTTP. + If this variable is set along with + NO_PACKAGE, then only the port's + DISTFILES will be available, and only via + FTP/HTTP. - NO_CDROM should be set to a string - describing the reason why the port cannot be redistributed - on CD-ROM. For instance, this should be used if the port's - license is for non-commercial use - only. - + NO_CDROM should be set to a string + describing the reason why the port cannot be redistributed + on CD-ROM. For instance, this should be used if the port's + license is for non-commercial use + only. + - - <varname>NOFETCHFILES</varname> + + <varname>NOFETCHFILES</varname> - Files defined in the NOFETCHFILES - variable are not fetchable from any of the - MASTER_SITES. An example of such a file - is when the file is supplied on CD-ROM by the vendor. + Files defined in the NOFETCHFILES + variable are not fetchable from any of the + MASTER_SITES. An example of such a file + is when the file is supplied on CD-ROM by the vendor. - Tools which check for the availability of these files - on the MASTER_SITES should ignore these - files and not report about them. - + Tools which check for the availability of these files + on the MASTER_SITES should ignore these + files and not report about them. + - - <varname>RESTRICTED</varname> + + <varname>RESTRICTED</varname> - Set this variable alone if the application's license - permits neither mirroring the application's - DISTFILES nor distributing the binary - package in any way. + Set this variable alone if the application's license + permits neither mirroring the application's + DISTFILES nor distributing the binary + package in any way. - NO_CDROM or - NO_PACKAGE should not be set along with - RESTRICTED since the latter variable - implies the former ones. + NO_CDROM or + NO_PACKAGE should not be set along with + RESTRICTED since the latter variable + implies the former ones. - RESTRICTED should be set to a string - describing the reason why the port cannot be redistributed. - Typically, this indicates that the port contains proprietary - software and that the user will need to manually download - the DISTFILES, possibly after registering - for the software or agreeing to accept the terms of an - EULA. - + RESTRICTED should be set to a string + describing the reason why the port cannot be redistributed. + Typically, this indicates that the port contains proprietary + software and that the user will need to manually download + the DISTFILES, possibly after registering + for the software or agreeing to accept the terms of an + EULA. + - - <varname>RESTRICTED_FILES</varname> + + <varname>RESTRICTED_FILES</varname> - When RESTRICTED or - NO_CDROM is set, this variable defaults - to ${DISTFILES} ${PATCHFILES}, otherwise - it is empty. If only some of the distribution files are - restricted, then set this variable to list them. + When RESTRICTED or + NO_CDROM is set, this variable defaults + to ${DISTFILES} ${PATCHFILES}, otherwise + it is empty. If only some of the distribution files are + restricted, then set this variable to list them. - + - - <varname>LEGAL_TEXT</varname> + + <varname>LEGAL_TEXT</varname> - If the port has legal concerns not addressed by the - above variables, the variable LEGAL_TEXT - should be set to a string explaining the concern. For - example, if special permission was obtained for &os; to - redistribute the binary, this variable should indicate - so. - + If the port has legal concerns not addressed by the + above variables, the variable LEGAL_TEXT + should be set to a string explaining the concern. For + example, if special permission was obtained for &os; to + redistribute the binary, this variable should indicate + so. + - - <filename>/usr/ports/LEGAL</filename> and - <varname>LEGAL</varname> + + <filename>/usr/ports/LEGAL</filename> and + <varname>LEGAL</varname> - A port which sets any of the above variables must also - be added to /usr/ports/LEGAL. The - first column is a glob which matches the restricted - distfiles. The second column is the port's origin. The - third column is the output of - make -VLEGAL. - + A port which sets any of the above variables must also + be added to /usr/ports/LEGAL. The + first column is a glob which matches the restricted + distfiles. The second column is the port's origin. The + third column is the output of + make -VLEGAL. + - - Examples + + Examples - The preferred way to state "the distfiles for this port - must be fetched manually" is as follows: + The preferred way to state "the distfiles for this port + must be fetched manually" is as follows: - .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) + .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) IGNORE= may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR} .endif - This both informs the user, and sets the proper metadata - on the user's machine for use by automated programs. + This both informs the user, and sets the proper metadata + on the user's machine for use by automated programs. - Note that this stanza must be preceded by an inclusion - of bsd.port.pre.mk. - - + Note that this stanza must be preceded by an inclusion + of bsd.port.pre.mk. + + - - Building Mechanisms + + Building Mechanisms - - Building Ports in Parallel + + Building Ports in Parallel - The &os; ports framework supports parallel building - using multiple make sub-processes, which - allows SMP systems to utilize all of - their available CPU power, allowing port - builds to be faster and more effective. + The &os; ports framework supports parallel building + using multiple make sub-processes, which + allows SMP systems to utilize all of + their available CPU power, allowing port + builds to be faster and more effective. - This is achieved by passing -jX flag - to &man.make.1; running on vendor code. This is the default - build behavior of ports. Unfortunately, not all ports - handle parallel building well and it may be required to - explicitly disable this feature by adding the - MAKE_JOBS_UNSAFE=yes variable. It is - used when a port is known to be broken with - -jX. + This is achieved by passing -jX flag + to &man.make.1; running on vendor code. This is the default + build behavior of ports. Unfortunately, not all ports + handle parallel building well and it may be required to + explicitly disable this feature by adding the + MAKE_JOBS_UNSAFE=yes variable. It is + used when a port is known to be broken with + -jX. + - + + <command>make</command>, <command>gmake</command>, + <command>fmake</command>, and <command>imake</command> - - <command>make</command>, <command>gmake</command>, - <command>fmake</command>, and <command>imake</command> + Several differing make + implementations exist. Ported software often requires a + particular implementation, like GNU + make, known in &os; as + gmake, or fmake, the + legacy &os; make. - Several differing make - implementations exist. Ported software often requires a - particular implementation, like GNU - make, known in &os; as - gmake, or fmake, the - legacy &os; make. + If the port uses GNU make, + add gmake to USES. If + the legacy &os; make is needed, add + fmake there. - If the port uses GNU make, - add gmake to USES. If - the legacy &os; make is needed, add - fmake there. + MAKE_CMD can be used to reference the + specific command configured by the USES + setting in the port's Makefile. In + rare cases when more than one make + implementation is listed in USES, the + variables GMAKE (for the + GNU version) or FMAKE + (for the legacy &os; version) are available. Most ports + should only use MAKE_CMD within the + application Makefiles in + WRKSRC to call the + make implementation expected by the + ported software. - MAKE_CMD can be used to reference the - specific command configured by the USES - setting in the port's Makefile. In - rare cases when more than one make - implementation is listed in USES, the - variables GMAKE (for the - GNU version) or FMAKE - (for the legacy &os; version) are available. Most ports - should only use MAKE_CMD within the - application Makefiles in - WRKSRC to call the - make implementation expected by the - ported software. + If your port is an X application that creates + Makefile files from + Imakefile files using + imake, then set + USES= imake. This will cause the + configure stage to automatically do an + xmkmf -a. If the + flag is a problem for your port, set + XMKMF=xmkmf. If the port uses + imake but does not understand the + install.man target, + NO_INSTALL_MANPAGES=yes should be + set. - If your port is an X application that creates - Makefile files from - Imakefile files using - imake, then set - USES= imake. This will cause the - configure stage to automatically do an - xmkmf -a. If the - flag is a problem for your port, set - XMKMF=xmkmf. If the port uses - imake but does not understand the - install.man target, - NO_INSTALL_MANPAGES=yes should be - set. + If your port's source Makefile has + something else than all as the + main build target, set ALL_TARGET + accordingly. Same goes for + install and + INSTALL_TARGET. + - If your port's source Makefile has - something else than all as the - main build target, set ALL_TARGET - accordingly. Same goes for - install and - INSTALL_TARGET. - + + <command>configure</command> Script - - <command>configure</command> Script + If your port uses the configure + script to generate Makefile files from + Makefile.in files, set + GNU_CONFIGURE=yes. If you want to give + extra arguments to the configure script + (the default argument is --prefix=${PREFIX} + --infodir=${PREFIX}/${INFO_PATH} + --mandir=${MANPREFIX}/man + --build=${CONFIGURE_TARGET}), set those + extra arguments in CONFIGURE_ARGS. Extra + environment variables can be passed using + CONFIGURE_ENV variable. - If your port uses the configure - script to generate Makefile files from - Makefile.in files, set - GNU_CONFIGURE=yes. If you want to give - extra arguments to the configure script - (the default argument is --prefix=${PREFIX} - --infodir=${PREFIX}/${INFO_PATH} - --mandir=${MANPREFIX}/man - --build=${CONFIGURE_TARGET}), set those - extra arguments in CONFIGURE_ARGS. Extra - environment variables can be passed using - CONFIGURE_ENV variable. + + Variables for Ports That Use + <command>configure</command> -
- Variables for Ports That Use - <command>configure</command> + + + + Variable + Means + + - - - - Variable - Means - - + + + GNU_CONFIGURE + The port uses configure + script to prepare build. + - - - GNU_CONFIGURE - The port uses configure - script to prepare build. - + + HAS_CONFIGURE + Same as GNU_CONFIGURE, + except default configure target is not added to + CONFIGURE_ARGS. + - - HAS_CONFIGURE - Same as GNU_CONFIGURE, - except default configure target is not added to - CONFIGURE_ARGS. - + + CONFIGURE_ARGS + Additional arguments passed to + configure script. + - - CONFIGURE_ARGS - Additional arguments passed to - configure script. - + + CONFIGURE_ENV + Additional environment variables to be set + for configure script run. + - - CONFIGURE_ENV - Additional environment variables to be set - for configure script run. - + + CONFIGURE_TARGET + Override default configure target. Default + value is + ${MACHINE_ARCH}-portbld-freebsd${OSREL}. + + + +
+ - - CONFIGURE_TARGET - Override default configure target. Default - value is - ${MACHINE_ARCH}-portbld-freebsd${OSREL}. - - - - - + + Using <command>cmake</command> - - Using <command>cmake</command> + For ports that use CMake, + define USES= cmake, or + USES= cmake:outsource to build in a + separate directory (see below). - For ports that use CMake, - define USES= cmake, or - USES= cmake:outsource to build in a - separate directory (see below). + + Variables for Ports That Use + <command>cmake</command> -
- Variables for Ports That Use - <command>cmake</command> + + + + Variable + Means + + - - - - Variable - Means - - + + + CMAKE_ARGS + Port specific CMake + flags to be passed to the cmake + binary. + - - - CMAKE_ARGS - Port specific CMake - flags to be passed to the cmake - binary. - + + CMAKE_BUILD_TYPE + Type of build (CMake + predefined build profiles). Default is + Release, or + Debug if + WITH_DEBUG is set. + - - CMAKE_BUILD_TYPE - Type of build (CMake - predefined build profiles). Default is - Release, or - Debug if - WITH_DEBUG is set. - + + CMAKE_ENV + Environment variables to be set for the + cmake binary. Default is + ${CONFIGURE_ENV}. + - - CMAKE_ENV - Environment variables to be set for the - cmake binary. Default is - ${CONFIGURE_ENV}. - + + CMAKE_SOURCE_PATH + Path to the source directory. Default is + ${WRKSRC}. + + + +
- - CMAKE_SOURCE_PATH - Path to the source directory. Default is - ${WRKSRC}. - - - - + + Variables the Users can define for + <command>cmake</command> builds -
- Variables the Users can define for - <command>cmake</command> builds + + + + Variable + Means + + - - - - Variable - Means - - + + + CMAKE_VERBOSE + Enable verbose build output. Default not set, + unless BATCH or + PACKAGE_BUILDING are set. + - - - CMAKE_VERBOSE - Enable verbose build output. Default not set, - unless BATCH or - PACKAGE_BUILDING are set. - + + CMAKE_NOCOLOR + Disables colour build output. Default not set, + unless BATCH or + PACKAGE_BUILDING are set. + + + +
- - CMAKE_NOCOLOR - Disables colour build output. Default not set, - unless BATCH or - PACKAGE_BUILDING are set. - - - - + CMake supports the following + build profiles: Debug, + Release, + RelWithDebInfo and + MinSizeRel. Debug and + Release profiles respect system + *FLAGS, RelWithDebInfo + and MinSizeRel will set + CFLAGS to -O2 -g and + -Os -DNDEBUG correspondingly. The + lower-cased value of CMAKE_BUILD_TYPE is + exported to the PLIST_SUB and should be + used if port installs *.cmake files + depending on the build type (see + deskutils/strigi for an + example). Please note that some projects may define their + own build profiles and/or force particular build type by + setting CMAKE_BUILD_TYPE in + CMakeLists.txt files. In order to + make a port for such a project respect + CFLAGS and WITH_DEBUG, + the CMAKE_BUILD_TYPE definitions must be + removed from those files. - CMake supports the following - build profiles: Debug, - Release, - RelWithDebInfo and - MinSizeRel. Debug and - Release profiles respect system - *FLAGS, RelWithDebInfo - and MinSizeRel will set - CFLAGS to -O2 -g and - -Os -DNDEBUG correspondingly. The - lower-cased value of CMAKE_BUILD_TYPE is - exported to the PLIST_SUB and should be - used if port installs *.cmake files - depending on the build type (see - deskutils/strigi for an - example). Please note that some projects may define their - own build profiles and/or force particular build type by - setting CMAKE_BUILD_TYPE in - CMakeLists.txt files. In order to - make a port for such a project respect - CFLAGS and WITH_DEBUG, - the CMAKE_BUILD_TYPE definitions must be - removed from those files. + Most CMake-based projects + support an out-of-source method of building. The + out-of-source build for a port can be requested by using the + :outsource suffix. When enabled, + CONFIGURE_WRKSRC, + BUILD_WRKSRC and + INSTALL_WRKSRC will be set to + ${WRKDIR}/.build and this + directory will be used to keep all files generated during + configuration and build stages, leaving the source directory + intact. - Most CMake-based projects - support an out-of-source method of building. The - out-of-source build for a port can be requested by using the - :outsource suffix. When enabled, - CONFIGURE_WRKSRC, - BUILD_WRKSRC and - INSTALL_WRKSRC will be set to - ${WRKDIR}/.build and this - directory will be used to keep all files generated during - configuration and build stages, leaving the source directory - intact. + + <literal>USES= cmake</literal> Example - - <literal>USES= cmake</literal> Example + The following snippet demonstrates the use of + CMake for a port. + CMAKE_SOURCE_PATH is not usually + required, but can be set when the sources are not located + in the top directory, or if only a subset of the project + is intended to be built by the port. - The following snippet demonstrates the use of - CMake for a port. - CMAKE_SOURCE_PATH is not usually - required, but can be set when the sources are not located - in the top directory, or if only a subset of the project - is intended to be built by the port. - - USES= cmake:outsource + USES= cmake:outsource CMAKE_SOURCE_PATH= ${WRKSRC}/subproject - - + + - - Using <command>scons</command> + + Using <command>scons</command> - If your port uses SCons, - define USE_SCONS=yes. + If your port uses SCons, + define USE_SCONS=yes. - - Variables for Ports That Use - <command>scons</command> +
+ Variables for Ports That Use + <command>scons</command> - - - - Variable - Means - - + + + + Variable + Means + + - - - SCONS_ARGS - Port specific SCons flags passed to the SCons - environment. - + + + SCONS_ARGS + Port specific SCons flags passed to the SCons + environment. + - - SCONS_BUILDENV - Variables to be set in system - environment. - + + SCONS_BUILDENV + Variables to be set in system + environment. + - - SCONS_ENV - Variables to be set in SCons - environment. - + + SCONS_ENV + Variables to be set in SCons + environment. + - - SCONS_TARGET - Last argument passed to SCons, similar to - MAKE_TARGET. - - - -
+ + SCONS_TARGET + Last argument passed to SCons, similar to + MAKE_TARGET. + + + + - To make third party SConstruct - respect everything that is passed to SCons in - SCONS_ENV (that is, most importantly, - CC/CXX/CFLAGS/CXXFLAGS), patch the - SConstruct so build - Environment is constructed like - this: + To make third party SConstruct + respect everything that is passed to SCons in + SCONS_ENV (that is, most importantly, + CC/CXX/CFLAGS/CXXFLAGS), patch the + SConstruct so build + Environment is constructed like + this: - env = Environment(**ARGUMENTS) + env = Environment(**ARGUMENTS) - It may be then modified with - env.Append and - env.Replace. - - + It may be then modified with + env.Append and + env.Replace. + + - - Using GNU Autotools + + Using GNU Autotools - - Introduction + + Introduction - The various GNU autotools provide an abstraction - mechanism for building a piece of software over a wide - variety of operating systems and machine architectures. - Within the Ports Collection, an individual port can make use - of these tools via a simple construct: + The various GNU autotools provide an abstraction + mechanism for building a piece of software over a wide + variety of operating systems and machine architectures. + Within the Ports Collection, an individual port can make use + of these tools via a simple construct: - USE_AUTOTOOLS= tool:version[:operation] ... + USE_AUTOTOOLS= tool:version[:operation] ... - At the time of writing, tool - can be one of libtool, - libltdl, autoconf, - autoheader, automake - or aclocal. + At the time of writing, tool + can be one of libtool, + libltdl, autoconf, + autoheader, automake + or aclocal. - version specifies the - particular tool revision to be used (see - devel/{automake,autoconf,libtool}[0-9]+ - for valid versions). + version specifies the + particular tool revision to be used (see + devel/{automake,autoconf,libtool}[0-9]+ + for valid versions). - operation is an optional - extension to modify how the tool is used. + operation is an optional + extension to modify how the tool is used. - Multiple tools can be specified at once, either by - including them all on a single line, or using the - += Makefile construct. + Multiple tools can be specified at once, either by + including them all on a single line, or using the + += Makefile construct. - Finally, there is the special tool, called - autotools, which is a convenience - function to bring in all available versions of the autotools - to allow for cross-development work. This can also be - accomplished by installing the - devel/autotools port. - + Finally, there is the special tool, called + autotools, which is a convenience + function to bring in all available versions of the autotools + to allow for cross-development work. This can also be + accomplished by installing the + devel/autotools port. + - - <command>libtool</command> + + <command>libtool</command> - Shared libraries using the GNU building framework - usually use libtool to adjust the - compilation and installation of shared libraries to match - the specifics of the underlying operating system. The usual - practice is to use copy of libtool - bundled with the application. In case you need to use - external libtool, you can use the version - provided by The Ports Collection: + Shared libraries using the GNU building framework + usually use libtool to adjust the + compilation and installation of shared libraries to match + the specifics of the underlying operating system. The usual + practice is to use copy of libtool + bundled with the application. In case you need to use + external libtool, you can use the version + provided by The Ports Collection: - USE_AUTOTOOLS= libtool:version[:env] + USE_AUTOTOOLS= libtool:version[:env] - With no additional operations, - libtool:version - tells the building framework to patch the configure script - with the system-installed copy of - libtool. The - GNU_CONFIGURE is implied. Further, a - number of make and shell variables will be assigned for - onward use by the port. See - bsd.autotools.mk for details. + With no additional operations, + libtool:version + tells the building framework to patch the configure script + with the system-installed copy of + libtool. The + GNU_CONFIGURE is implied. Further, a + number of make and shell variables will be assigned for + onward use by the port. See + bsd.autotools.mk for details. - With the :env operation, only the - environment will be set up. + With the :env operation, only the + environment will be set up. - Finally, LIBTOOLFLAGS and - LIBTOOLFILES can be optionally set to - override the most likely arguments to, and files patched by, - libtool. Most ports are unlikely to need - this. See bsd.autotools.mk for further - details. - + Finally, LIBTOOLFLAGS and + LIBTOOLFILES can be optionally set to + override the most likely arguments to, and files patched by, + libtool. Most ports are unlikely to need + this. See bsd.autotools.mk for further + details. + - - <command>libltdl</command> + + <command>libltdl</command> - Some ports make use of the libltdl - library package, which is part of the - libtool suite. Use of this library does - not automatically necessitate the use of - libtool itself, so a separate construct - is provided. + Some ports make use of the libltdl + library package, which is part of the + libtool suite. Use of this library does + not automatically necessitate the use of + libtool itself, so a separate construct + is provided. - USE_AUTOTOOLS= libltdl:version + USE_AUTOTOOLS= libltdl:version - Currently, all this does is to bring in a - LIB_DEPENDS on the appropriate - libltdl port, and is provided as a - convenience function to help eliminate any dependencies on - the autotools ports outside of the - USE_AUTOTOOLS framework. There are no - optional operations for this tool. - + Currently, all this does is to bring in a + LIB_DEPENDS on the appropriate + libltdl port, and is provided as a + convenience function to help eliminate any dependencies on + the autotools ports outside of the + USE_AUTOTOOLS framework. There are no + optional operations for this tool. + - - <command>autoconf</command> and - <command>autoheader</command> + + <command>autoconf</command> and + <command>autoheader</command> - Some ports do not contain a configure script, but do - contain an autoconf template in the - configure.ac file. You can use the - following assignments to let autoconf - create the configure script, and also have - autoheader create template headers for - use by the configure script. + Some ports do not contain a configure script, but do + contain an autoconf template in the + configure.ac file. You can use the + following assignments to let autoconf + create the configure script, and also have + autoheader create template headers for + use by the configure script. - USE_AUTOTOOLS= autoconf:version[:env] + USE_AUTOTOOLS= autoconf:version[:env] - and + and - USE_AUTOTOOLS= autoheader:version + USE_AUTOTOOLS= autoheader:version - which also implies the use of - autoconf:version. + which also implies the use of + autoconf:version. - Similarly to libtool, the inclusion - of the optional :env operation simply - sets up the environment for further use. Without it, - patching and reconfiguration of the port is carried - out. + Similarly to libtool, the inclusion + of the optional :env operation simply + sets up the environment for further use. Without it, + patching and reconfiguration of the port is carried + out. - The additional optional variables - AUTOCONF_ARGS and - AUTOHEADER_ARGS can be overridden by the - port Makefile if specifically - requested. As with the libtool - equivalents, most ports are unlikely to need this. - + The additional optional variables + AUTOCONF_ARGS and + AUTOHEADER_ARGS can be overridden by the + port Makefile if specifically + requested. As with the libtool + equivalents, most ports are unlikely to need this. + - - <command>automake</command> and - <command>aclocal</command> + + <command>automake</command> and + <command>aclocal</command> - Some packages only contain - Makefile.am files. These have to be - converted into Makefile.in files using - automake, and the further processed by - configure to generate an actual - Makefile. + Some packages only contain + Makefile.am files. These have to be + converted into Makefile.in files using + automake, and the further processed by + configure to generate an actual + Makefile. - Similarly, packages occasionally do not ship with - included aclocal.m4 files, again - required to build the software. This can be achieved with - aclocal, which scans - configure.ac or - configure.in. + Similarly, packages occasionally do not ship with + included aclocal.m4 files, again + required to build the software. This can be achieved with + aclocal, which scans + configure.ac or + configure.in. - aclocal has a similar relationship to - automake as autoheader - does to autoconf, described in the - previous section. aclocal implies the - use of automake, thus we have: + aclocal has a similar relationship to + automake as autoheader + does to autoconf, described in the + previous section. aclocal implies the + use of automake, thus we have: - USE_AUTOTOOLS= automake:version[:env] + USE_AUTOTOOLS= automake:version[:env] - and + and - USE_AUTOTOOLS= aclocal:version + USE_AUTOTOOLS= aclocal:version - which also implies the use of - automake:version. + which also implies the use of + automake:version. - Similarly to libtool and - autoconf, the inclusion of the optional - :env operation simply sets up the - environment for further use. Without it, reconfiguration of - the port is carried out. + Similarly to libtool and + autoconf, the inclusion of the optional + :env operation simply sets up the + environment for further use. Without it, reconfiguration of + the port is carried out. - As with autoconf and - autoheader, both - automake and aclocal - have optional argument variables, - AUTOMAKE_ARGS and - ACLOCAL_ARGS respectively, which may be - overridden by the port Makefile if - required. - - + As with autoconf and + autoheader, both + automake and aclocal + have optional argument variables, + AUTOMAKE_ARGS and + ACLOCAL_ARGS respectively, which may be + overridden by the port Makefile if + required. + + - - Using GNU <literal>gettext</literal> + + Using GNU <literal>gettext</literal> - - Basic Usage + + Basic Usage - If your port requires gettext, set - USES= gettext, and your port will inherit - a dependency on - devel/gettext. Other - values for gettext usage are listed in - . + If your port requires gettext, set + USES= gettext, and your port will inherit + a dependency on + devel/gettext. Other + values for gettext usage are listed in + . - A rather common case is a port using - gettext and configure. - Generally, GNU configure should be able - to locate gettext automatically. If it - ever fails to, hints at the location of - gettext can be passed in - CPPFLAGS and LDFLAGS as - follows: + A rather common case is a port using + gettext and configure. + Generally, GNU configure should be able + to locate gettext automatically. If it + ever fails to, hints at the location of + gettext can be passed in + CPPFLAGS and LDFLAGS as + follows: - USES= gettext + USES= gettext CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib GNU_CONFIGURE= yes - Of course, the code can be more compact if there are no - more flags to pass to configure: + Of course, the code can be more compact if there are no + more flags to pass to configure: - USES= gettext + USES= gettext GNU_CONFIGURE= yes - + - - Optional Usage + + Optional Usage - Some software products allow for disabling NLS, e.g., - through passing to - configure. In that case, your port - should use gettext conditionally, - depending on the status of the NLS - option. For ports of low to medium complexity, you can rely - on the following idiom: + Some software products allow for disabling NLS, e.g., + through passing to + configure. In that case, your port + should use gettext conditionally, + depending on the status of the NLS + option. For ports of low to medium complexity, you can rely + on the following idiom: - GNU_CONFIGURE= yes + GNU_CONFIGURE= yes .include <bsd.port.options.mk> @@ -866,575 +867,574 @@ PLIST_SUB+= NLS="@comment " .include <bsd.port.mk> - The next item on your to-do list is to arrange so that - the message catalog files are included in the packing list - conditionally. The Makefile part of - this task is already provided by the idiom. It is explained - in the section on advanced - pkg-plist practices. In a - nutshell, each occurrence of %%NLS%% in - pkg-plist will be replaced by - @comment  if NLS is - disabled, or by a null string if NLS is enabled. - Consequently, the lines prefixed by - %%NLS%% will become mere comments in the - final packing list if NLS is off; otherwise the prefix will - be just left out. All you need to do now is insert - %%NLS%% before each path to a message - catalog file in pkg-plist. For - example: + The next item on your to-do list is to arrange so that + the message catalog files are included in the packing list + conditionally. The Makefile part of + this task is already provided by the idiom. It is explained + in the section on advanced + pkg-plist practices. In a + nutshell, each occurrence of %%NLS%% in + pkg-plist will be replaced by + @comment  if NLS is + disabled, or by a null string if NLS is enabled. + Consequently, the lines prefixed by + %%NLS%% will become mere comments in the + final packing list if NLS is off; otherwise the prefix will + be just left out. All you need to do now is insert + %%NLS%% before each path to a message + catalog file in pkg-plist. For + example: - %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo + %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo - In high complexity cases, you may need to use more - advanced techniques than the recipe given here, such as - dynamic packing list - generation. - + In high complexity cases, you may need to use more + advanced techniques than the recipe given here, such as + dynamic packing list + generation. + - - Handling Message Catalog Directories + + Handling Message Catalog Directories - There is a point to note about installing message - catalog files. The target directories for them, which - reside under - LOCALBASE/share/locale, - should rarely be created and removed by a port. The most - popular languages have their respective directories listed - in - PORTSDIR/Templates/BSD.local.dist. - The directories for many other languages are governed by the - devel/gettext port. - Consult its pkg-plist and see whether - the port is going to install a message catalog file for a - unique language. - - + There is a point to note about installing message + catalog files. The target directories for them, which + reside under + LOCALBASE/share/locale, + should rarely be created and removed by a port. The most + popular languages have their respective directories listed + in + PORTSDIR/Templates/BSD.local.dist. + The directories for many other languages are governed by the + devel/gettext port. + Consult its pkg-plist and see whether + the port is going to install a message catalog file for a + unique language. + + - - Using <application>Perl</application> + + Using <application>Perl</application> - If MASTER_SITES is set to - MASTER_SITE_PERL_CPAN, then the preferred - value of MASTER_SITE_SUBDIR is the - top-level hierarchy name. For example, the recommended value - for p5-Module-Name is - Module. The top-level hierarchy can be - examined at cpan.org. - This keeps the port working when the author of the module - changes. + If MASTER_SITES is set to + MASTER_SITE_PERL_CPAN, then the preferred + value of MASTER_SITE_SUBDIR is the + top-level hierarchy name. For example, the recommended value + for p5-Module-Name is + Module. The top-level hierarchy can be + examined at cpan.org. + This keeps the port working when the author of the module + changes. - The exception to this rule is when the relevant directory - does not exist or the distfile does not exist in that - directory. In such case, using author's id as - MASTER_SITE_SUBDIR is allowed. + The exception to this rule is when the relevant directory + does not exist or the distfile does not exist in that + directory. In such case, using author's id as + MASTER_SITE_SUBDIR is allowed. - All of the tunable knobs below accept either - YES or a version string like - 5.8.0+. YES means - that the port can be used with any of the supported - Perl versions. If a port only - works with specific versions of - Perl, it can be indicated with a - version string, specifying a minimum version (e.g., - 5.7.3+), a maximum version (e.g., - 5.8.0-) or an exact version (e.g., - 5.8.3). + All of the tunable knobs below accept either + YES or a version string like + 5.8.0+. YES means + that the port can be used with any of the supported + Perl versions. If a port only + works with specific versions of + Perl, it can be indicated with a + version string, specifying a minimum version (e.g., + 5.7.3+), a maximum version (e.g., + 5.8.0-) or an exact version (e.g., + 5.8.3). + + + Variables for Ports That Use + <application>Perl</application> + + + + + Variable + Meaning + + + + + + USE_PERL5 + The port uses Perl 5 + to build and run. + + + + USE_PERL5_BUILD + The port uses Perl 5 + to build. + + + + USE_PERL5_RUN + The port uses Perl 5 + to run. + + + + PERL + The full path of the Perl 5 interpreter, + either in the system or installed from a port, but + without the version number. Use this if you need to + replace #!lines in + scripts. + + + + PERL_CONFIGURE + Configure using Perl's MakeMaker. It implies + USE_PERL5. + + + + PERL_MODBUILD + Configure, build and install using Module::Build. + It implies PERL_CONFIGURE. + + + + + + + + Read only variables + Means + + + + + + PERL_VERSION + The full version of Perl + installed (e.g., 5.8.9). + + + + PERL_LEVEL + The installed Perl version as + an integer of the form MNNNPP + (e.g., 500809). + + + + PERL_ARCH + Where Perl stores architecture + dependent libraries. Defaults to + ${ARCH}-freebsd. + + + + PERL_PORT + Name of the Perl port that is + installed (e.g., perl5). + + + + SITE_PERL + Directory name where site specific + Perl packages go. This value is + added to PLIST_SUB. + + + +
+ + + Ports of Perl modules which do not have an official + website should link to cpan.org in + the WWW line of pkg-descr. The + preferred URL form is + http://search.cpan.org/dist/Module-Name/ + (including the trailing slash). + + + + Do not use ${SITE_PERL} in dependency + declarations. Doing so assumes that + bsd.perl.mk has been included, which is + not always true. Ports depending on this port will have + incorrect dependencies if this port's files move later in an + upgrade. The right way to declare Perl module dependencies + is shown in the example below. + + + + Perl Dependency Example + + p5-IO-Tee>=0.64:${PORTSDIR}/devel/p5-IO-Tee + + + For Perl ports that install manual pages, the macro + PERL5_MANx + (where x ranges from + 1 to 9) can be used + inside pkg-plist. For example, + + lib/perl5/5.14/man/man3/AnyEvent::I3.3.gz + + can be replaced with + + %%PERL5_MAN3%%/AnyEvent::I3.3.gz + + + + Using X11 + + + X.Org Components + + The X11 implementation available in The Ports Collection + is X.Org. If your application depends on X components, set + USE_XORG to the list of required + components. Available components, at the time of writing, + are: + + bigreqsproto compositeproto damageproto dmx + dmxproto dri2proto evieproto fixesproto fontcacheproto + fontenc fontsproto fontutil glproto ice inputproto kbproto + libfs oldx pciaccess pixman printproto randrproto + recordproto renderproto resourceproto scrnsaverproto sm + trapproto videoproto x11 xau xaw xaw6 xaw7 xbitmaps + xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext + xextproto xf86bigfontproto xf86dgaproto xf86driproto + xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont + xfontcache xft xi xinerama xineramaproto xkbfile xkbui + xmu xmuu xorg-server xp xpm xprintapputil xprintutil + xproto xproxymngproto xrandr xrender xres xscrnsaver xt + xtrans xtrap xtst xv xvmc xxf86dga xxf86misc + xxf86vm. + + Always up-to-date list can be found in + /usr/ports/Mk/bsd.xorg.mk. + + The Mesa Project is an effort to provide free OpenGL + implementation. You can specify a dependency on various + components of this project with USE_GL + variable. Valid options are: + glut, glu, glw, glew, gl and + linux. For backwards compatibility, the + value of yes maps to + glu. + + + USE_XORG Example + + USE_XORG= xrender xft xkbfile xt xaw +USE_GL= glu + - Variables for Ports That Use - <application>Perl</application> + Variables for Ports That Use X - - - Variable - Meaning - - - - USE_PERL5 - The port uses Perl 5 - to build and run. + USES= imake + The port uses imake. - USE_PERL5_BUILD - The port uses Perl 5 - to build. - - - - USE_PERL5_RUN - The port uses Perl 5 - to run. - - - - PERL - The full path of the Perl 5 interpreter, - either in the system or installed from a port, but - without the version number. Use this if you need to - replace #!lines in - scripts. - - - - PERL_CONFIGURE - Configure using Perl's MakeMaker. It implies - USE_PERL5. - - - - PERL_MODBUILD - Configure, build and install using Module::Build. - It implies PERL_CONFIGURE. - - - - - - - - Read only variables - Means - - - - - - PERL_VERSION - The full version of Perl - installed (e.g., 5.8.9). - - - - PERL_LEVEL - The installed Perl version as - an integer of the form MNNNPP - (e.g., 500809). - - - - PERL_ARCH - Where Perl stores architecture - dependent libraries. Defaults to - ${ARCH}-freebsd. - - - - PERL_PORT - Name of the Perl port that is - installed (e.g., perl5). - - - - SITE_PERL - Directory name where site specific - Perl packages go. This value is - added to PLIST_SUB. + XMKMF + Set to the path of xmkmf if + not in the PATH. Defaults to + xmkmf -a.
- - Ports of Perl modules which do not have an official - website should link to cpan.org in - the WWW line of pkg-descr. The - preferred URL form is - http://search.cpan.org/dist/Module-Name/ - (including the trailing slash). - + + Using X11-Related Variables - - Do not use ${SITE_PERL} in dependency - declarations. Doing so assumes that - bsd.perl.mk has been included, which is - not always true. Ports depending on this port will have - incorrect dependencies if this port's files move later in an - upgrade. The right way to declare Perl module dependencies - is shown in the example below. - - - - Perl Dependency Example - - p5-IO-Tee>=0.64:${PORTSDIR}/devel/p5-IO-Tee - - - For Perl ports that install manual pages, the macro - PERL5_MANx - (where x ranges from - 1 to 9) can be used - inside pkg-plist. For example, - - lib/perl5/5.14/man/man3/AnyEvent::I3.3.gz - - can be replaced with - - %%PERL5_MAN3%%/AnyEvent::I3.3.gz - - - - Using X11 - - - X.Org Components - - The X11 implementation available in The Ports Collection - is X.Org. If your application depends on X components, set - USE_XORG to the list of required - components. Available components, at the time of writing, - are: - - bigreqsproto compositeproto damageproto dmx - dmxproto dri2proto evieproto fixesproto fontcacheproto - fontenc fontsproto fontutil glproto ice inputproto kbproto - libfs oldx pciaccess pixman printproto randrproto - recordproto renderproto resourceproto scrnsaverproto sm - trapproto videoproto x11 xau xaw xaw6 xaw7 xbitmaps - xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext - xextproto xf86bigfontproto xf86dgaproto xf86driproto - xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont - xfontcache xft xi xinerama xineramaproto xkbfile xkbui - xmu xmuu xorg-server xp xpm xprintapputil xprintutil - xproto xproxymngproto xrandr xrender xres xscrnsaver xt - xtrans xtrap xtst xv xvmc xxf86dga xxf86misc - xxf86vm. - - Always up-to-date list can be found in - /usr/ports/Mk/bsd.xorg.mk. - - The Mesa Project is an effort to provide free OpenGL - implementation. You can specify a dependency on various - components of this project with USE_GL - variable. Valid options are: - glut, glu, glw, glew, gl and - linux. For backwards compatibility, the - value of yes maps to - glu. - - - USE_XORG Example - - USE_XORG= xrender xft xkbfile xt xaw -USE_GL= glu - - - - Variables for Ports That Use X - - - - - USES= imake - The port uses imake. - - - - XMKMF - Set to the path of xmkmf if - not in the PATH. Defaults to - xmkmf -a. - - - -
- - - Using X11-Related Variables - - # Use some X11 libraries + # Use some X11 libraries USE_XORG= x11 xpm - - + + - - Ports That Require Motif + + Ports That Require Motif - If your port requires a Motif library, define - USES= motif in the - Makefile. Default Motif implementation - is - x11-toolkits/open-motif. - Users can choose - x11-toolkits/lesstif - instead by setting WANT_LESSTIF - variable. + If your port requires a Motif library, define + USES= motif in the + Makefile. Default Motif implementation + is + x11-toolkits/open-motif. + Users can choose + x11-toolkits/lesstif + instead by setting WANT_LESSTIF + variable. - The MOTIFLIB variable will be set by - bsd.port.mk to reference the - appropriate Motif library. Please patch the source of your - port to use ${MOTIFLIB} wherever - the Motif library is referenced in the original - Makefile or - Imakefile. + The MOTIFLIB variable will be set by + bsd.port.mk to reference the + appropriate Motif library. Please patch the source of your + port to use ${MOTIFLIB} wherever + the Motif library is referenced in the original + Makefile or + Imakefile. - There are two common cases: + There are two common cases: - - - If the port refers to the Motif library as - -lXm in its - Makefile or - Imakefile, simply substitute - ${MOTIFLIB} for it. - + + + If the port refers to the Motif library as + -lXm in its + Makefile or + Imakefile, simply substitute + ${MOTIFLIB} for it. + - - If the port uses XmClientLibs in - its Imakefile, change it to - ${MOTIFLIB} ${XTOOLLIB} - ${XLIB}. - - + + If the port uses XmClientLibs in + its Imakefile, change it to + ${MOTIFLIB} ${XTOOLLIB} + ${XLIB}. + + - Note that MOTIFLIB (usually) expands - to -L/usr/local/lib -lXm or - /usr/local/lib/libXm.a, so there is no - need to add -L or -l - in front. - + Note that MOTIFLIB (usually) expands + to -L/usr/local/lib -lXm or + /usr/local/lib/libXm.a, so there is no + need to add -L or -l + in front. + - - X11 Fonts + + X11 Fonts - If your port installs fonts for the X Window System, put - them in - LOCALBASE/lib/X11/fonts/local. - + If your port installs fonts for the X Window System, put + them in + LOCALBASE/lib/X11/fonts/local. + - - Getting a Fake <envar>DISPLAY</envar> with Xvfb + + Getting a Fake <envar>DISPLAY</envar> with Xvfb - Some applications require a working X11 display for - compilation to succeed. This pose a problem for machines - that operate headless. When the following variable is used, - the build infrastructure will start the virtual framebuffer - X server. The working DISPLAY is then passed - to the build. + Some applications require a working X11 display for + compilation to succeed. This pose a problem for machines + that operate headless. When the following variable is used, + the build infrastructure will start the virtual framebuffer + X server. The working DISPLAY is then passed + to the build. - USES= display - + USES= display + - - Desktop Entries + + Desktop Entries - Desktop entries (a - Freedesktop standard) provide a way to - automatically adjust desktop features when a new program is - installed, without requiring user intervention. For - example, newly-installed programs automatically appear in - the application menus of compatible desktop environments. - Desktop entries originated in the - GNOME desktop environment, but - are now a standard and also work with - KDE and - Xfce. This bit of automation - provides a real benefit to the user, and desktop entries are - encouraged for applications which can be used in a desktop - environment. + Desktop entries (a + Freedesktop standard) provide a way to + automatically adjust desktop features when a new program is + installed, without requiring user intervention. For + example, newly-installed programs automatically appear in + the application menus of compatible desktop environments. + Desktop entries originated in the + GNOME desktop environment, but + are now a standard and also work with + KDE and + Xfce. This bit of automation + provides a real benefit to the user, and desktop entries are + encouraged for applications which can be used in a desktop + environment. - - Using Predefined <filename>.desktop</filename> - Files + + Using Predefined <filename>.desktop</filename> + Files - Ports that include predefined - *.desktop files should - include those files in pkg-plist - and install them in the - $LOCALBASE/share/applications - directory. The INSTALL_DATA - macro is useful for installing these - files. - + Ports that include predefined + *.desktop files should + include those files in pkg-plist + and install them in the + $LOCALBASE/share/applications + directory. The INSTALL_DATA + macro is useful for installing these + files. + - - Updating Desktop Database + + Updating Desktop Database - If a port has a MimeType entry in its - portname.desktop, - the desktop database must be updated after install and - deinstall. To do this, define USES= - desktop-file-utils. + If a port has a MimeType entry in its + portname.desktop, + the desktop database must be updated after install and + deinstall. To do this, define USES= + desktop-file-utils. - + - - Creating Desktop Entries with the - <varname>DESKTOP_ENTRIES</varname> Macro + + Creating Desktop Entries with the + <varname>DESKTOP_ENTRIES</varname> Macro - Desktop entries can be easily created for applications - by using the DESKTOP_ENTRIES variable. - A file named - name.desktop - will be created, installed, and added to the - pkg-plist automatically. Syntax - is: + Desktop entries can be easily created for applications + by using the DESKTOP_ENTRIES variable. + A file named + name.desktop + will be created, installed, and added to the + pkg-plist automatically. Syntax + is: - DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify + DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify - The list of possible categories is available on the - Freedesktop - website. StartupNotify - indicates whether the application is compatible with - startup notifications. These are - typically a graphic indicator like a clock that appear at - the mouse pointer, menu, or panel to give the user an - indication when a program is starting. A program that is - compatible with startup notifications clears the indicator - after it has started. Programs that are not compatible - with startup notifications would never clear the indicator - (potentially confusing and infuriating the user), and - should have StartupNotify set to - false so the indicator is not shown at - all. + The list of possible categories is available on the + Freedesktop + website. StartupNotify + indicates whether the application is compatible with + startup notifications. These are + typically a graphic indicator like a clock that appear at + the mouse pointer, menu, or panel to give the user an + indication when a program is starting. A program that is + compatible with startup notifications clears the indicator + after it has started. Programs that are not compatible + with startup notifications would never clear the indicator + (potentially confusing and infuriating the user), and + should have StartupNotify set to + false so the indicator is not shown at + all. - Example: + Example: - DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ + DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ "${DATADIR}/xtra/graf/tome-128.png" \ "tome -v -g" "Application;Game;RolePlaying;" \ false + + + - - - + + Using GNOME - - Using GNOME + The &os;/GNOME project uses its own set of variables to + define which GNOME components a particular port uses. A comprehensive + list of these variables exists within the + &os;/GNOME project's homepage. + - The &os;/GNOME project uses its own set of variables to - define which GNOME components a particular port uses. A comprehensive - list of these variables exists within the - &os;/GNOME project's homepage. - + + Using Qt - - Using Qt + + Ports That Require Qt - - Ports That Require Qt + + Variables for Ports That Use Qt -
- Variables for Ports That Use Qt + + + + USE_QT4 + Specify tool and library dependencies for ports + that use Qt 4. See + Qt 4 component + selection for more details. + - - - - USE_QT4 - Specify tool and library dependencies for ports - that use Qt 4. See - Qt 4 component - selection for more details. - + + QT_PREFIX + Set to the path where Qt installed to + (read-only variable). + - - QT_PREFIX - Set to the path where Qt installed to - (read-only variable). - + + MOC + Set to the path of moc + (read-only variable). Default set according to + USE_QT_VER value. + - - MOC - Set to the path of moc - (read-only variable). Default set according to - USE_QT_VER value. - + + QTCPPFLAGS + Additional compiler flags passed via + CONFIGURE_ENV for Qt toolkit. + Default set according to + USE_QT_VER. + - - QTCPPFLAGS - Additional compiler flags passed via - CONFIGURE_ENV for Qt toolkit. - Default set according to - USE_QT_VER. - + + QTCFGLIBS + Additional libraries for linking passed via + CONFIGURE_ENV for Qt toolkit. + Default set according to + USE_QT_VER. + - - QTCFGLIBS - Additional libraries for linking passed via - CONFIGURE_ENV for Qt toolkit. - Default set according to - USE_QT_VER. - + + QTNONSTANDARD + Suppress modification of + CONFIGURE_ENV, + CONFIGURE_ARGS, + CPPFLAGS and + MAKE_ENV. + + + +
- - QTNONSTANDARD - Suppress modification of - CONFIGURE_ENV, - CONFIGURE_ARGS, - CPPFLAGS and - MAKE_ENV. - - - - + + Additional Variables for Ports That Use Qt + 4.x -
- Additional Variables for Ports That Use Qt - 4.x + + + + UIC + Set to the path of uic + (read-only variable). + - - - - UIC - Set to the path of uic - (read-only variable). - + + QMAKE + Set to the path of qmake + (read-only variable). + - - QMAKE - Set to the path of qmake - (read-only variable). - + + QMAKESPEC + Set to the path of configuration file for + qmake (read-only + variable). + - - QMAKESPEC - Set to the path of configuration file for - qmake (read-only - variable). - + + QMAKEFLAGS + Additional flags for + qmake. + - - QMAKEFLAGS - Additional flags for - qmake. - + + QT_INCDIR + Set to Qt 4 include directories (read-only + variable). + - - QT_INCDIR - Set to Qt 4 include directories (read-only - variable). - + + QT_LIBDIR + Set to Qt 4 libraries path (read-only + variable). + - - QT_LIBDIR - Set to Qt 4 libraries path (read-only - variable). - + + QT_PLUGINDIR + Set to Qt 4 plugins path (read-only + variable). + + + +
- - QT_PLUGINDIR - Set to Qt 4 plugins path (read-only - variable). - - - - + When USE_QT4 is set, the following + settings are deployed: - When USE_QT4 is set, the following - settings are deployed: - - CONFIGURE_ARGS+= --with-qt-includes=${QT_INCDIR} \ + CONFIGURE_ARGS+= --with-qt-includes=${QT_INCDIR} \ --with-qt-libraries=${QT_LIBDIR} \ --with-extra-libs=${LOCALBASE}/lib \ --with-extra-includes=${LOCALBASE}/include @@ -1445,819 +1445,819 @@ MAKE_ENV+= QMAKESPEC="${QMAKESPEC}" PLIST_SUB+= QT_INCDIR_REL=${QT_INCDIR_REL} \ QT_LIBDIR_REL=${QT_LIBDIR_REL} \ QT_PLUGINDIR_REL=${QT_PLUGINDIR_REL} - + - - Component Selection + + Component Selection - Individual Qt 4 tool and library dependencies must be - specified in the USE_QT4 variable. Every - component can be suffixed by either - _build or _run, the - suffix indicating whether the component should be depended - on at buildtime or runtime, respectively. If unsuffixed, - the component will be depended on at both build- and - runtime. Usually, library components should be specified - unsuffixed, tool components should be specified with the - _build suffix and plugin components - should be specified with the _run suffix. - The most commonly used components are listed below (all - available components are listed in - _USE_QT4_ALL in - /usr/ports/Mk/bsd.qt.mk): + Individual Qt 4 tool and library dependencies must be + specified in the USE_QT4 variable. Every + component can be suffixed by either + _build or _run, the + suffix indicating whether the component should be depended + on at buildtime or runtime, respectively. If unsuffixed, + the component will be depended on at both build- and + runtime. Usually, library components should be specified + unsuffixed, tool components should be specified with the + _build suffix and plugin components + should be specified with the _run suffix. + The most commonly used components are listed below (all + available components are listed in + _USE_QT4_ALL in + /usr/ports/Mk/bsd.qt.mk): - - Available Qt 4 Library Components +
+ Available Qt 4 Library Components - - - - Name - Description - - + + + + Name + Description + + - - - corelib - core library (can be omitted unless the port - uses nothing but corelib) - + + + corelib + core library (can be omitted unless the port + uses nothing but corelib) + - - gui - graphical user interface library - + + gui + graphical user interface library + - - network - network library - + + network + network library + - - opengl - OpenGL library - + + opengl + OpenGL library + - - qt3support - Qt 3 compatibility library - + + qt3support + Qt 3 compatibility library + - - qtestlib - unit testing library - + + qtestlib + unit testing library + - - script - script library - + + script + script library + - - sql - SQL library - + + sql + SQL library + - - xml - XML library - - - -
+ + xml + XML library + + + + - You can determine which libraries the application - depends on, by running ldd on the main - executable after a successful compilation. + You can determine which libraries the application + depends on, by running ldd on the main + executable after a successful compilation. - - Available Qt 4 Tool Components +
+ Available Qt 4 Tool Components - - - - Name - Description - - + + + + Name + Description + + - - - moc - meta object compiler (needed for almost - every Qt application at buildtime) - + + + moc + meta object compiler (needed for almost + every Qt application at buildtime) + - - qmake - Makefile generator / build utility - + + qmake + Makefile generator / build utility + - - rcc - resource compiler (needed if the application - comes with *.rc or - *.qrc files) - + + rcc + resource compiler (needed if the application + comes with *.rc or + *.qrc files) + - - uic - user interface compiler (needed if the - application comes with *.ui - files created by Qt Designer - in practice, every Qt - application with a GUI) - - - -
+ + uic + user interface compiler (needed if the + application comes with *.ui + files created by Qt Designer - in practice, every Qt + application with a GUI) + + + + - - Available Qt 4 Plugin Components +
+ Available Qt 4 Plugin Components - - - - Name - Description - - + + + + Name + Description + + - - - iconengines - SVG icon engine plugin (if the application - ships SVG icons) - + + + iconengines + SVG icon engine plugin (if the application + ships SVG icons) + - - imageformats - imageformat plugins for GIF, JPEG, MNG and - SVG (if the application ships image files) - - - -
+ + imageformats + imageformat plugins for GIF, JPEG, MNG and + SVG (if the application ships image files) + + + + - - Selecting Qt 4 Components + + Selecting Qt 4 Components - In this example, the ported application uses the Qt 4 - graphical user interface library, the Qt 4 core library, - all of the Qt 4 code generation tools and Qt 4's Makefile - generator. Since the gui library - implies a dependency on the core library, - corelib does not need to be specified. - The Qt 4 code generation tools moc, - uic and rcc, as well - as the Makefile generator qmake are - only needed at buildtime, thus they are specified with the - _build suffix: + In this example, the ported application uses the Qt 4 + graphical user interface library, the Qt 4 core library, + all of the Qt 4 code generation tools and Qt 4's Makefile + generator. Since the gui library + implies a dependency on the core library, + corelib does not need to be specified. + The Qt 4 code generation tools moc, + uic and rcc, as well + as the Makefile generator qmake are + only needed at buildtime, thus they are specified with the + _build suffix: - USE_QT4= gui moc_build qmake_build rcc_build uic_build - - + USE_QT4= gui moc_build qmake_build rcc_build uic_build + + - - Using <command>qmake</command> + + Using <command>qmake</command> - - Variables for Ports That Use - <command>qmake</command> +
+ Variables for Ports That Use + <command>qmake</command> - - - - Variable - Means - - + + + + Variable + Means + + - - - QMAKE_ARGS - Port specific QMake - flags to be passed to the qmake - binary. - + + + QMAKE_ARGS + Port specific QMake + flags to be passed to the qmake + binary. + - - QMAKE_ENV - Environment variables to be set for the - qmake binary. The default is - ${CONFIGURE_ENV}. - + + QMAKE_ENV + Environment variables to be set for the + qmake binary. The default is + ${CONFIGURE_ENV}. + - - QMAKE_PRO - Name of the project .pro - file. The default is empty (using - autodetection). - - - -
+ + QMAKE_PRO + Name of the project .pro + file. The default is empty (using + autodetection). + + + + - If the application does not provide a - configure script but a - .pro file, you can use the - following: + If the application does not provide a + configure script but a + .pro file, you can use the + following: - USES= qmake + USES= qmake USE_QT4= qmake_build - USES=qmake instructs the port to - use qmake for configuring. - Note that USES=qmake does not imply a - dependency on Qt 4 qmake, thus - USE_QT4 has to be populated with the - qmake_build component. + USES=qmake instructs the port to + use qmake for configuring. + Note that USES=qmake does not imply a + dependency on Qt 4 qmake, thus + USE_QT4 has to be populated with the + qmake_build component. - Qt applications often are written to be cross-platform - and often X11/Unix is not the platform they are developed - on, which in turn often leads to certain loose ends, - like: + Qt applications often are written to be cross-platform + and often X11/Unix is not the platform they are developed + on, which in turn often leads to certain loose ends, + like: - - - Missing additional include - paths. Many applications come with - system tray icon support, but neglect to look for - includes and/or libraries in the X11 directories. You - can tell qmake to add directories to - the include and library search paths via the command - line, for example: + + + Missing additional include + paths. Many applications come with + system tray icon support, but neglect to look for + includes and/or libraries in the X11 directories. You + can tell qmake to add directories to + the include and library search paths via the command + line, for example: - QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \ + QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \ LIBS+=-L${LOCALBASE}/lib - + - - Bogus installation paths. - Sometimes data such as icons or .desktop files are by - default installed into directories which are not scanned - by XDG-compatible applications. - editors/texmaker is - an example for this - look at - patch-texmaker.pro in the - files directory of that port for a - template on how to remedy this directly in the - qmake project file. - - - - + + Bogus installation paths. + Sometimes data such as icons or .desktop files are by + default installed into directories which are not scanned + by XDG-compatible applications. + editors/texmaker is + an example for this - look at + patch-texmaker.pro in the + files directory of that port for a + template on how to remedy this directly in the + qmake project file. + + + + - - Using KDE + + Using KDE - - KDE 4 Variable Definitions + + KDE 4 Variable Definitions - If your application depends on KDE 4.x, set - USE_KDE4 to the list of required - components. _build and - _run suffixes can be used to force - components dependency type (e.g., - baseapps_run). If no suffix is set, a - default dependency type will be used. If you want to force - both types, add the component twice with both suffixes - (e.g., automoc4_build automoc4_run). The - most commonly used components are listed below (up-to-date - components are documented at the top of - /usr/ports/Mk/bsd.kde4.mk): + If your application depends on KDE 4.x, set + USE_KDE4 to the list of required + components. _build and + _run suffixes can be used to force + components dependency type (e.g., + baseapps_run). If no suffix is set, a + default dependency type will be used. If you want to force + both types, add the component twice with both suffixes + (e.g., automoc4_build automoc4_run). The + most commonly used components are listed below (up-to-date + components are documented at the top of + /usr/ports/Mk/bsd.kde4.mk): - - Available KDE 4 Components +
+ Available KDE 4 Components - - - - Name - Description - - + + + + Name + Description + + - - - kdehier - Hierarchy of common KDE directories - + + + kdehier + Hierarchy of common KDE directories + - - kdelibs - KDE Developer Platform - + + kdelibs + KDE Developer Platform + - - kdeprefix - If set, port will be installed into - ${KDE4_PREFIX} instead of - ${LOCALBASE} - + + kdeprefix + If set, port will be installed into + ${KDE4_PREFIX} instead of + ${LOCALBASE} + - - sharedmime - MIME types database for KDE ports - + + sharedmime + MIME types database for KDE ports + - - automoc4 - Automatic moc for Qt 4 packages - + + automoc4 + Automatic moc for Qt 4 packages + - - akonadi - Storage server for KDE-Pim - + + akonadi + Storage server for KDE-Pim + - - soprano - Qt 4 RDF framework - + + soprano + Qt 4 RDF framework + - - strigi - Desktop search daemon - + + strigi + Desktop search daemon + - - libkcddb - KDE CDDB library - + + libkcddb + KDE CDDB library + - - libkcompactdisc - KDE library for interfacing with audio - CDs - + + libkcompactdisc + KDE library for interfacing with audio + CDs + - - libkdeedu - Libraries used by educational - applications - + + libkdeedu + Libraries used by educational + applications + - - libkdcraw - KDE LibRaw library - + + libkdcraw + KDE LibRaw library + - - libkexiv2 - KDE Exiv2 library - + + libkexiv2 + KDE Exiv2 library + - - libkipi - KDE Image Plugin Interface - + + libkipi + KDE Image Plugin Interface + - - libkonq - Konqueror core library - + + libkonq + Konqueror core library + - - libksane - KDE SANE ("Scanner Access Now Easy") - library - + + libksane + KDE SANE ("Scanner Access Now Easy") + library + - - pimlibs - KDE-Pim libraries - + + pimlibs + KDE-Pim libraries + - - kate - Text editor framework - + + kate + Text editor framework + - - marble - Virtual globe - + + marble + Virtual globe + - - okular - Universal document viewer - + + okular + Universal document viewer + - - korundum - KDE Ruby bindings - + + korundum + KDE Ruby bindings + - - perlkde - KDE Perl bindings - + + perlkde + KDE Perl bindings + - - pykde4 - KDE Python bindings - + + pykde4 + KDE Python bindings + - - pykdeuic4 - PyKDE user interface compiler - + + pykdeuic4 + PyKDE user interface compiler + - - smokekde - KDE SMOKE libraries - - - -
+ + smokekde + KDE SMOKE libraries + + + + - KDE 4.x ports are installed into - KDE4_PREFIX, which is - /usr/local/kde4 currently. This is - achieved by specifying the kdeprefix - component, which overrides the default - PREFIX. The ports however respect any - PREFIX set via MAKEFLAGS - environment variable and/or make - arguments. + KDE 4.x ports are installed into + KDE4_PREFIX, which is + /usr/local/kde4 currently. This is + achieved by specifying the kdeprefix + component, which overrides the default + PREFIX. The ports however respect any + PREFIX set via MAKEFLAGS + environment variable and/or make + arguments. - - <varname>USE_KDE4</varname> Example + + <varname>USE_KDE4</varname> Example - This is a simple example for a KDE 4 port. - USES= cmake:outsource instructs the - port to utilize CMake, a - configuration tool widely used by KDE 4 projects (see - for detailed usage). - USE_KDE4 brings dependency on KDE - libraries and makes port using - automoc4 at build stage. - Required KDE components and other dependencies can be - determined through configure log. - USE_KDE4 does not imply - USE_QT4. If a port requires some - Qt 4 components, they should be specified in - USE_QT4. + This is a simple example for a KDE 4 port. + USES= cmake:outsource instructs the + port to utilize CMake, a + configuration tool widely used by KDE 4 projects (see + for detailed usage). + USE_KDE4 brings dependency on KDE + libraries and makes port using + automoc4 at build stage. + Required KDE components and other dependencies can be + determined through configure log. + USE_KDE4 does not imply + USE_QT4. If a port requires some + Qt 4 components, they should be specified in + USE_QT4. - USES= cmake:outsource + USES= cmake:outsource USE_KDE4= kdelibs kdeprefix automoc4 USE_QT4= moc_build qmake_build rcc_build uic_build - - - + + + - - Using Java + + Using Java - - Variable Definitions + + Variable Definitions - If your port needs a Java™ Development Kit - (JDK™) to either build, run or even extract the - distfile, then it should define - USE_JAVA. + If your port needs a Java™ Development Kit + (JDK™) to either build, run or even extract the + distfile, then it should define + USE_JAVA. - There are several JDKs in the ports collection, from - various vendors, and in several versions. If your port must - use one of these versions, you can define which one. The - most current version, and &os; default is - java/openjdk6. + There are several JDKs in the ports collection, from + various vendors, and in several versions. If your port must + use one of these versions, you can define which one. The + most current version, and &os; default is + java/openjdk6. - - Variables Which May be Set by Ports That Use - Java +
+ Variables Which May be Set by Ports That Use + Java - - - - Variable - Means - - + + + + Variable + Means + + - - - USE_JAVA - Should be defined for the remaining variables - to have any effect. - + + + USE_JAVA + Should be defined for the remaining variables + to have any effect. + - - JAVA_VERSION - List of space-separated suitable Java versions - for the port. An optional "+" - allows you to specify a range of versions (allowed - values: - 1.5[+] 1.6[+] 1.7[+]). - + + JAVA_VERSION + List of space-separated suitable Java versions + for the port. An optional "+" + allows you to specify a range of versions (allowed + values: + 1.5[+] 1.6[+] 1.7[+]). + - - JAVA_OS - List of space-separated suitable JDK port - operating systems for the port (allowed values: - native linux). - + + JAVA_OS + List of space-separated suitable JDK port + operating systems for the port (allowed values: + native linux). + - - JAVA_VENDOR - List of space-separated suitable JDK port - vendors for the port (allowed values: - freebsd bsdjava sun - openjdk). - + + JAVA_VENDOR + List of space-separated suitable JDK port + vendors for the port (allowed values: + freebsd bsdjava sun + openjdk). + - - JAVA_BUILD - When set, it means that the selected JDK port - should be added to the build dependencies of the - port. - + + JAVA_BUILD + When set, it means that the selected JDK port + should be added to the build dependencies of the + port. + - - JAVA_RUN - When set, it means that the selected JDK port - should be added to the run dependencies of the - port. - + + JAVA_RUN + When set, it means that the selected JDK port + should be added to the run dependencies of the + port. + - - JAVA_EXTRACT - When set, it means that the selected JDK port - should be added to the extract dependencies of the - port. - - - -
+ + JAVA_EXTRACT + When set, it means that the selected JDK port + should be added to the extract dependencies of the + port. + + + + - Below is the list of all settings a port will receive - after setting USE_JAVA: + Below is the list of all settings a port will receive + after setting USE_JAVA: - - Variables Provided to Ports That Use Java +
+ Variables Provided to Ports That Use Java - - - - Variable - Value - - + + + + Variable + Value + + - - - JAVA_PORT - The name of the JDK port (e.g., - 'java/openjdk6'). - + + + JAVA_PORT + The name of the JDK port (e.g., + 'java/openjdk6'). + - - JAVA_PORT_VERSION - The full version of the JDK port (e.g., - '1.6.0'). If you only need the - first two digits of this version number, use - ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}. - + + JAVA_PORT_VERSION + The full version of the JDK port (e.g., + '1.6.0'). If you only need the + first two digits of this version number, use + ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}. + - - JAVA_PORT_OS - The operating system used by the JDK port - (e.g., 'native'). - + + JAVA_PORT_OS + The operating system used by the JDK port + (e.g., 'native'). + - - JAVA_PORT_VENDOR - The vendor of the JDK port (e.g., - 'openjdk'). - + + JAVA_PORT_VENDOR + The vendor of the JDK port (e.g., + 'openjdk'). + - - JAVA_PORT_OS_DESCRIPTION - Description of the operating system used by the - JDK port (e.g., - 'Native'). - + + JAVA_PORT_OS_DESCRIPTION + Description of the operating system used by the + JDK port (e.g., + 'Native'). + - - JAVA_PORT_VENDOR_DESCRIPTION - Description of the vendor of the JDK port - (e.g., 'OpenJDK BSD Porting - Team'). - + + JAVA_PORT_VENDOR_DESCRIPTION + Description of the vendor of the JDK port + (e.g., 'OpenJDK BSD Porting + Team'). + - - JAVA_HOME - Path to the installation directory of the JDK - (e.g., - '/usr/local/openjdk6'). - + + JAVA_HOME + Path to the installation directory of the JDK + (e.g., + '/usr/local/openjdk6'). + - - JAVAC - Path to the Java compiler to use (e.g., - '/usr/local/openjdk6/bin/javac'). - + + JAVAC + Path to the Java compiler to use (e.g., + '/usr/local/openjdk6/bin/javac'). + - - JAR - Path to the jar tool to use - (e.g., - '/usr/local/openjdk6/bin/jar' - or - '/usr/local/bin/fastjar'). - + + JAR + Path to the jar tool to use + (e.g., + '/usr/local/openjdk6/bin/jar' + or + '/usr/local/bin/fastjar'). + - - APPLETVIEWER - Path to the appletviewer - utility (e.g., - '/usr/local/openjdk6/bin/appletviewer'). - + + APPLETVIEWER + Path to the appletviewer + utility (e.g., + '/usr/local/openjdk6/bin/appletviewer'). + - - JAVA - Path to the java executable. - Use this for executing Java programs (e.g., - '/usr/local/openjdk6/bin/java'). - + + JAVA + Path to the java executable. + Use this for executing Java programs (e.g., + '/usr/local/openjdk6/bin/java'). + - - JAVADOC - Path to the javadoc utility - program. - + + JAVADOC + Path to the javadoc utility + program. + - - JAVAH - Path to the javah - program. - + + JAVAH + Path to the javah + program. + - - JAVAP - Path to the javap - program. - + + JAVAP + Path to the javap + program. + - - JAVA_KEYTOOL - Path to the keytool utility - program. - + + JAVA_KEYTOOL + Path to the keytool utility + program. + - - JAVA_N2A - Path to the native2ascii - tool. - + + JAVA_N2A + Path to the native2ascii + tool. + - - JAVA_POLICYTOOL - Path to the policytool - program. - + + JAVA_POLICYTOOL + Path to the policytool + program. + - - JAVA_SERIALVER - Path to the serialver - utility program. - + + JAVA_SERIALVER + Path to the serialver + utility program. + - - RMIC - Path to the RMI stub/skeleton generator, - rmic. - + + RMIC + Path to the RMI stub/skeleton generator, + rmic. + - - RMIREGISTRY - Path to the RMI registry program, - rmiregistry. - + + RMIREGISTRY + Path to the RMI registry program, + rmiregistry. + - - RMID - Path to the RMI daemon program - rmid. - + + RMID + Path to the RMI daemon program + rmid. + - - JAVA_CLASSES - Path to the archive that contains the JDK class - files, - ${JAVA_HOME}/jre/lib/rt.jar. - - - -
+ + JAVA_CLASSES + Path to the archive that contains the JDK class + files, + ${JAVA_HOME}/jre/lib/rt.jar. + + + + - You may use the java-debug make - target to get information for debugging your port. It will - display the value of many of the forecited variables. + You may use the java-debug make + target to get information for debugging your port. It will + display the value of many of the forecited variables. - Additionally, the following constants are defined so all - Java ports may be installed in a consistent way: + Additionally, the following constants are defined so all + Java ports may be installed in a consistent way: - - Constants Defined for Ports That Use Java +
+ Constants Defined for Ports That Use Java - - - - Constant - Value - - + + + + Constant + Value + + - - - JAVASHAREDIR - The base directory for everything related to - Java. Default: - ${PREFIX}/share/java. - + + + JAVASHAREDIR + The base directory for everything related to + Java. Default: + ${PREFIX}/share/java. + - - JAVAJARDIR - The directory where JAR files should be - installed. Default: - ${JAVASHAREDIR}/classes. - + + JAVAJARDIR + The directory where JAR files should be + installed. Default: + ${JAVASHAREDIR}/classes. + - - JAVALIBDIR - The directory where JAR files installed by - other ports are located. Default: - ${LOCALBASE}/share/java/classes. - - - -
+ + JAVALIBDIR + The directory where JAR files installed by + other ports are located. Default: + ${LOCALBASE}/share/java/classes. + + + + - The related entries are defined in both - PLIST_SUB (documented in - ) and - SUB_LIST. - + The related entries are defined in both + PLIST_SUB (documented in + ) and + SUB_LIST. + - - Building with Ant + + Building with Ant - When the port is to be built using Apache Ant, it has to - define USE_ANT. Ant is thus considered - to be the sub-make command. When no - do-build target is defined by the port, a - default one will be set that simply runs Ant according to - MAKE_ENV, MAKE_ARGS - and ALL_TARGET. This is similar to the - USES= gmake mechanism, which is - documented in . - + When the port is to be built using Apache Ant, it has to + define USE_ANT. Ant is thus considered + to be the sub-make command. When no + do-build target is defined by the port, a + default one will be set that simply runs Ant according to + MAKE_ENV, MAKE_ARGS + and ALL_TARGET. This is similar to the + USES= gmake mechanism, which is + documented in . + - - Best Practices + + Best Practices - When porting a Java library, your port should install - the JAR file(s) in ${JAVAJARDIR}, and - everything else under - ${JAVASHAREDIR}/${PORTNAME} (except for - the documentation, see below). In order to reduce the - packing file size, you may reference the JAR file(s) - directly in the Makefile. Just use the - following statement (where myport.jar - is the name of the JAR file installed as part of the - port): + When porting a Java library, your port should install + the JAR file(s) in ${JAVAJARDIR}, and + everything else under + ${JAVASHAREDIR}/${PORTNAME} (except for + the documentation, see below). In order to reduce the + packing file size, you may reference the JAR file(s) + directly in the Makefile. Just use the + following statement (where myport.jar + is the name of the JAR file installed as part of the + port): - PLIST_FILES+= %%JAVAJARDIR%%/myport.jar + PLIST_FILES+= %%JAVAJARDIR%%/myport.jar - When porting a Java application, the port usually - installs everything under a single directory (including its - JAR dependencies). The use of - ${JAVASHAREDIR}/${PORTNAME} is strongly - encouraged in this regard. It is up the porter to decide - whether the port should install the additional JAR - dependencies under this directory or directly use the - already installed ones (from - ${JAVAJARDIR}). + When porting a Java application, the port usually + installs everything under a single directory (including its + JAR dependencies). The use of + ${JAVASHAREDIR}/${PORTNAME} is strongly + encouraged in this regard. It is up the porter to decide + whether the port should install the additional JAR + dependencies under this directory or directly use the + already installed ones (from + ${JAVAJARDIR}). - When porting a &java; application that requires an - application server such as - www/tomcat7 to run the - service, it is quite common for a vendor to distribute a - .war file. A .war - file is a Web application ARchive and is extracted when - called by the application. Avoid adding a - .war - file to the pkg-plist. - It is not considered best practice. An application server - will expand the war archive, but not - clean it up properly if the port is removed. A more - desirable way of working with this file is to extract the - archive, then install the files, and lastly add these files - to pkg-plist. + When porting a &java; application that requires an + application server such as + www/tomcat7 to run the + service, it is quite common for a vendor to distribute a + .war file. A .war + file is a Web application ARchive and is extracted when + called by the application. Avoid adding a + .war + file to the pkg-plist. + It is not considered best practice. An application server + will expand the war archive, but not + clean it up properly if the port is removed. A more + desirable way of working with this file is to extract the + archive, then install the files, and lastly add these files + to pkg-plist. - TOMCATDIR= ${LOCALBASE}/apache-tomcat-7.0 + TOMCATDIR= ${LOCALBASE}/apache-tomcat-7.0 WEBAPPDIR= myapplication post-extract: @@ -2269,320 +2269,320 @@ do-install: ${INSTALL} -d -o ${WWWOWN} -g ${WWWGRP} ${TOMCATDIR}/webapps/${PORTDIRNAME} @cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME} - Regardless of the type of your port (library or - application), the additional documentation should be - installed in the - same location - as for any other port. The JavaDoc tool is known to produce - a different set of files depending on the version of the JDK - that is used. For ports that do not enforce the use of a - particular JDK, it is therefore a complex task to specify - the packing list (pkg-plist). This is - one reason why porters are strongly encouraged to use the - PORTDOCS macro. Moreover, even if you - can predict the set of files that will be generated by - javadoc, the size of the resulting - pkg-plist advocates for the use of - PORTDOCS. + Regardless of the type of your port (library or + application), the additional documentation should be + installed in the + same location + as for any other port. The JavaDoc tool is known to produce + a different set of files depending on the version of the JDK + that is used. For ports that do not enforce the use of a + particular JDK, it is therefore a complex task to specify + the packing list (pkg-plist). This is + one reason why porters are strongly encouraged to use the + PORTDOCS macro. Moreover, even if you + can predict the set of files that will be generated by + javadoc, the size of the resulting + pkg-plist advocates for the use of + PORTDOCS. - The default value for DATADIR is - ${PREFIX}/share/${PORTNAME}. It is a - good idea to override DATADIR to - ${JAVASHAREDIR}/${PORTNAME} for Java - ports. Indeed, DATADIR is automatically - added to PLIST_SUB (documented in - ) so you may use - %%DATADIR%% directly in - pkg-plist. + The default value for DATADIR is + ${PREFIX}/share/${PORTNAME}. It is a + good idea to override DATADIR to + ${JAVASHAREDIR}/${PORTNAME} for Java + ports. Indeed, DATADIR is automatically + added to PLIST_SUB (documented in + ) so you may use + %%DATADIR%% directly in + pkg-plist. - As for the choice of building Java ports from source or - directly installing them from a binary distribution, there - is no defined policy at the time of writing. However, - people from the - &os; Java - Project encourage porters to have their ports - built from source whenever it is a trivial task. + As for the choice of building Java ports from source or + directly installing them from a binary distribution, there + is no defined policy at the time of writing. However, + people from the + &os; Java + Project encourage porters to have their ports + built from source whenever it is a trivial task. - All the features that have been presented in this - section are implemented in bsd.java.mk. - If you ever think that your port needs more sophisticated - Java support, please first have a look at the bsd.java.mk - Subversion log as it - usually takes some time to document the latest features. - Then, if you think the support you are lacking would be - beneficial to many other Java ports, feel free to discuss it - on the &a.java;. + All the features that have been presented in this + section are implemented in bsd.java.mk. + If you ever think that your port needs more sophisticated + Java support, please first have a look at the bsd.java.mk + Subversion log as it + usually takes some time to document the latest features. + Then, if you think the support you are lacking would be + beneficial to many other Java ports, feel free to discuss it + on the &a.java;. - Although there is a java category for - PRs, it refers to the JDK porting effort from the &os; Java - project. Therefore, you should submit your Java port in the - ports category as for any other port, - unless the issue you are trying to resolve is related to - either a JDK implementation or - bsd.java.mk. + Although there is a java category for + PRs, it refers to the JDK porting effort from the &os; Java + project. Therefore, you should submit your Java port in the + ports category as for any other port, + unless the issue you are trying to resolve is related to + either a JDK implementation or + bsd.java.mk. - Similarly, there is a defined policy regarding the - CATEGORIES of a Java port, which is - detailed in . - - + Similarly, there is a defined policy regarding the + CATEGORIES of a Java port, which is + detailed in . + + - - Web Applications, Apache and PHP + + Web Applications, Apache and PHP - - Apache + + Apache - - Variables for Ports That Use Apache +
+ Variables for Ports That Use Apache - - + + - - USE_APACHE - The port requires Apache. Possible values: - yes (gets any version), - 22, 24, - 22-24, 22+, - etc. The default APACHE version is - 22. More details are available - in ports/Mk/bsd.apache.mk and - at wiki.freebsd.org/Apache/. - + + USE_APACHE + The port requires Apache. Possible values: + yes (gets any version), + 22, 24, + 22-24, 22+, + etc. The default APACHE version is + 22. More details are available + in ports/Mk/bsd.apache.mk and + at wiki.freebsd.org/Apache/. + - - APXS - Full path to the apxs - binary. Can be overridden in your port. - + + APXS + Full path to the apxs + binary. Can be overridden in your port. + - - HTTPD - Full path to the httpd - binary. Can be overridden in your port. - + + HTTPD + Full path to the httpd + binary. Can be overridden in your port. + - - APACHE_VERSION - The version of present Apache installation - (read-only variable). This variable is only - available after inclusion of - bsd.port.pre.mk. Possible - values: 22, - 24. - + + APACHE_VERSION + The version of present Apache installation + (read-only variable). This variable is only + available after inclusion of + bsd.port.pre.mk. Possible + values: 22, + 24. + - - APACHEMODDIR - Directory for Apache modules. This variable is - automatically expanded in - pkg-plist. - + + APACHEMODDIR + Directory for Apache modules. This variable is + automatically expanded in + pkg-plist. + - - APACHEINCLUDEDIR - Directory for Apache headers. This variable is - automatically expanded in - pkg-plist. - + + APACHEINCLUDEDIR + Directory for Apache headers. This variable is + automatically expanded in + pkg-plist. + - - APACHEETCDIR - Directory for Apache configuration files. This - variable is automatically expanded in - pkg-plist. - - - -
+ + APACHEETCDIR + Directory for Apache configuration files. This + variable is automatically expanded in + pkg-plist. + + + + - - Useful Variables for Porting Apache Modules +
+ Useful Variables for Porting Apache Modules - - + + - - MODULENAME - Name of the module. Default value is - PORTNAME. Example: - mod_hello - + + MODULENAME + Name of the module. Default value is + PORTNAME. Example: + mod_hello + - - SHORTMODNAME - Short name of the module. Automatically - derived from MODULENAME, but can - be overridden. Example: - hello - + + SHORTMODNAME + Short name of the module. Automatically + derived from MODULENAME, but can + be overridden. Example: + hello + - - AP_FAST_BUILD - Use apxs to compile and - install the module. - + + AP_FAST_BUILD + Use apxs to compile and + install the module. + - - AP_GENPLIST - Also automatically creates a - pkg-plist. - + + AP_GENPLIST + Also automatically creates a + pkg-plist. + - - AP_INC - Adds a directory to a header search path during - compilation. - + + AP_INC + Adds a directory to a header search path during + compilation. + - - AP_LIB - Adds a directory to a library search path - during compilation. - + + AP_LIB + Adds a directory to a library search path + during compilation. + - - AP_EXTRAS - Additional flags to pass to - apxs. - - - -
- + + AP_EXTRAS + Additional flags to pass to + apxs. + + + + + - - Web Applications + + Web Applications - Web applications should be installed into - PREFIX/www/appname. - For your convenience, this path is available both in - Makefile and in - pkg-plist as WWWDIR, - and the path relative to PREFIX is - available in Makefile as - WWWDIR_REL. + Web applications should be installed into + PREFIX/www/appname. + For your convenience, this path is available both in + Makefile and in + pkg-plist as WWWDIR, + and the path relative to PREFIX is + available in Makefile as + WWWDIR_REL. - The user and group of web server process are available - as WWWOWN and WWWGRP, - in case you need to change the ownership of some files. The - default values of both are www. If you - want different values for your port, use - WWWOWN?= myuser notation, to allow user - to override it easily. + The user and group of web server process are available + as WWWOWN and WWWGRP, + in case you need to change the ownership of some files. The + default values of both are www. If you + want different values for your port, use + WWWOWN?= myuser notation, to allow user + to override it easily. - Do not depend on Apache unless the web app explicitly - needs Apache. Respect that users may wish to run your web - app on different web server than Apache. - + Do not depend on Apache unless the web app explicitly + needs Apache. Respect that users may wish to run your web + app on different web server than Apache. + - - PHP + + PHP - - Variables for Ports That Use PHP +
+ Variables for Ports That Use PHP - - - - USE_PHP - The port requires PHP. The value - yes adds a dependency on PHP. - The list of required PHP extensions can be specified - instead. Example: - pcre xml gettext - + + + + USE_PHP + The port requires PHP. The value + yes adds a dependency on PHP. + The list of required PHP extensions can be specified + instead. Example: + pcre xml gettext + - - DEFAULT_PHP_VER - Selects which major version of PHP will be - installed as a dependency when no PHP is installed - yet. Default is 5. Possible - values: 4, - 5 - + + DEFAULT_PHP_VER + Selects which major version of PHP will be + installed as a dependency when no PHP is installed + yet. Default is 5. Possible + values: 4, + 5 + - - IGNORE_WITH_PHP - The port does not work with PHP of the given - version. Possible values: 4, - 5 - + + IGNORE_WITH_PHP + The port does not work with PHP of the given + version. Possible values: 4, + 5 + - - USE_PHPIZE - The port will be built as a PHP - extension. - + + USE_PHPIZE + The port will be built as a PHP + extension. + - - USE_PHPEXT - The port will be treated as a PHP extension, - including installation and registration in the - extension registry. - + + USE_PHPEXT + The port will be treated as a PHP extension, + including installation and registration in the + extension registry. + - - USE_PHP_BUILD - Set PHP as a build dependency. - + + USE_PHP_BUILD + Set PHP as a build dependency. + - - WANT_PHP_CLI - Want the CLI (command line) version of - PHP. - + + WANT_PHP_CLI + Want the CLI (command line) version of + PHP. + - - WANT_PHP_CGI - Want the CGI version of PHP. - + + WANT_PHP_CGI + Want the CGI version of PHP. + - - WANT_PHP_MOD - Want the Apache module version of PHP. - + + WANT_PHP_MOD + Want the Apache module version of PHP. + - - WANT_PHP_SCR - Want the CLI or the CGI version of PHP. - + + WANT_PHP_SCR + Want the CLI or the CGI version of PHP. + - - WANT_PHP_WEB - Want the Apache module or the CGI version of - PHP. - - - -
- + + WANT_PHP_WEB + Want the Apache module or the CGI version of + PHP. + + + + + - - PEAR Modules + + PEAR Modules - Porting PEAR modules is a very simple process. + Porting PEAR modules is a very simple process. - Use the variables FILES, - TESTS, DATA, - SQLS, SCRIPTFILES, - DOCS and EXAMPLES to - list the files you want to install. All listed files will - be automatically installed into the appropriate locations - and added to pkg-plist. + Use the variables FILES, + TESTS, DATA, + SQLS, SCRIPTFILES, + DOCS and EXAMPLES to + list the files you want to install. All listed files will + be automatically installed into the appropriate locations + and added to pkg-plist. - Include - ${PORTSDIR}/devel/pear/bsd.pear.mk - on the last line of the - Makefile. + Include + ${PORTSDIR}/devel/pear/bsd.pear.mk + on the last line of the + Makefile. - - Example Makefile for PEAR Class + + Example Makefile for PEAR Class - PORTNAME= Date + PORTNAME= Date PORTVERSION= 1.4.3 CATEGORIES= devel www pear @@ -2606,509 +2606,507 @@ _DOCSDIR= . .include <bsd.port.pre.mk> .include "${PORTSDIR}/devel/pear/bsd.pear.mk" .include <bsd.port.post.mk> - - - + + + - - Using Python + + Using Python - The Ports Collection supports parallel installation of - multiple Python versions. Ports should make sure to use a - correct python interpreter, according to - the user-settable PYTHON_VERSION variable. - Most prominently, this means replacing the path to - python executable in scripts with the value - of PYTHON_CMD variable. + The Ports Collection supports parallel installation of + multiple Python versions. Ports should make sure to use a + correct python interpreter, according to + the user-settable PYTHON_VERSION variable. + Most prominently, this means replacing the path to + python executable in scripts with the value + of PYTHON_CMD variable. - Ports that install files under - PYTHON_SITELIBDIR should use the - pyXY- package name prefix, so their package - name embeds the version of Python they are installed - into. + Ports that install files under + PYTHON_SITELIBDIR should use the + pyXY- package name prefix, so their package + name embeds the version of Python they are installed + into. - PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} + PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} - - Most Useful Variables for Ports That Use Python +
+ Most Useful Variables for Ports That Use Python - - - - USE_PYTHON - The port needs Python. Minimal required version - can be specified with values such as - 2.6+. Version ranges can also be - specified, by separating two version numbers with a - dash, e.g.: 2.6-2.7 - + + + + USE_PYTHON + The port needs Python. Minimal required version + can be specified with values such as + 2.6+. Version ranges can also be + specified, by separating two version numbers with a + dash, e.g.: 2.6-2.7 + - - USE_PYDISTUTILS - Use Python distutils for configuring, compiling - and installing. This is required when the port comes - with setup.py. This overrides - the do-build and - do-install targets and may - also override do-configure - if GNU_CONFIGURE is not - defined. - + + USE_PYDISTUTILS + Use Python distutils for configuring, compiling + and installing. This is required when the port comes + with setup.py. This overrides + the do-build and + do-install targets and may + also override do-configure + if GNU_CONFIGURE is not + defined. + - - PYTHON_PKGNAMEPREFIX - Used as a PKGNAMEPREFIX to - distinguish packages for different Python versions. - Example: py24- - + + PYTHON_PKGNAMEPREFIX + Used as a PKGNAMEPREFIX to + distinguish packages for different Python versions. + Example: py24- + - - PYTHON_SITELIBDIR - Location of the site-packages tree, that contains - installation path of Python (usually - LOCALBASE). The - PYTHON_SITELIBDIR variable can be - very useful when installing Python modules. - + + PYTHON_SITELIBDIR + Location of the site-packages tree, that contains + installation path of Python (usually + LOCALBASE). The + PYTHON_SITELIBDIR variable can be + very useful when installing Python modules. + - - PYTHONPREFIX_SITELIBDIR - The PREFIX-clean variant of PYTHON_SITELIBDIR. - Always use %%PYTHON_SITELIBDIR%% in - pkg-plist when possible. The - default value of - %%PYTHON_SITELIBDIR%% is - lib/python%%PYTHON_VERSION%%/site-packages - + + PYTHONPREFIX_SITELIBDIR + The PREFIX-clean variant of PYTHON_SITELIBDIR. + Always use %%PYTHON_SITELIBDIR%% in + pkg-plist when possible. The + default value of + %%PYTHON_SITELIBDIR%% is + lib/python%%PYTHON_VERSION%%/site-packages + - - PYTHON_CMD - Python interpreter command line, including - version number. - + + PYTHON_CMD + Python interpreter command line, including + version number. + - - PYNUMERIC - Dependency line for numeric extension. - + + PYNUMERIC + Dependency line for numeric extension. + - - PYNUMPY - Dependency line for the new numeric extension, - numpy. (PYNUMERIC is deprecated by upstream - vendor). - + + PYNUMPY + Dependency line for the new numeric extension, + numpy. (PYNUMERIC is deprecated by upstream + vendor). + - - PYXML - Dependency line for XML extension (not needed for - Python 2.0 and higher as it is also in base - distribution). - + + PYXML + Dependency line for XML extension (not needed for + Python 2.0 and higher as it is also in base + distribution). + + + +
- - - + A complete list of available variables can be found in + /usr/ports/Mk/bsd.python.mk. - A complete list of available variables can be found in - /usr/ports/Mk/bsd.python.mk. + Some Python applications claim to have + DESTDIR support (which would be required + for staging) but it is broken (Mailman up to 2.1.16, for + instance). This can be worked around by recompiling the + scripts. This can be done, for example, in the + post-build target. Assuming the + Python scripts are supposed to reside in + PYTHONPREFIX_SITELIBDIR after installation, + this solution can be applied: - Some Python applications claim to have - DESTDIR support (which would be required - for staging) but it is broken (Mailman up to 2.1.16, for - instance). This can be worked around by recompiling the - scripts. This can be done, for example, in the - post-build target. Assuming the - Python scripts are supposed to reside in - PYTHONPREFIX_SITELIBDIR after installation, - this solution can be applied: - - (cd ${STAGEDIR}${PREFIX} \ + (cd ${STAGEDIR}${PREFIX} \ && ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \ -d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;}) - This recompiles the sources with a path relative to the - stage directory, and prepends the value of - PREFIX to the file name recorded in the - byte-compiled output file by -d. - -f is required to force recompilation, and - the :S;${PREFIX}/;; strips prefixes from - the value of the PYTHONPREFIX_SITELIBDIR - variable to make it relative to - PREFIX. - - Python 2.7 or newer is required for this. It does - not work with Python 2.6. - - - - Using <application>Tcl/Tk</application> - - The Ports Collection supports parallel installation of - multiple Tcl/Tk versions. Ports - should try to support at least the default - Tcl/Tk version and higher with the - USE_TCL and USE_TK - variables. It is possible to specify the desired version of - tcl with the - WITH_TCL_VER variable. - - - The Most Useful Variables for Ports That Use - <application>Tcl/Tk</application> - - - - - USE_TCL - The port depends on the - Tcl library (not the - shell). Minimal required version can be specified - with values such as 84+. Individual unsupported - versions can be specified with the - INVALID_TCL_VER variable. - - - - USE_TCL_BUILD - The port needs Tcl - only during the build time. - - - - USE_TCL_WRAPPER - Ports that require the - Tcl shell and do not - require a specific tclsh version - should use this new variable. The - tclsh wrapper is installed on the - system. The user can specify the desired - tcl shell to use. - - - - WITH_TCL_VER - User-defined variable that sets the desired - Tcl version. - - - - UNIQUENAME_WITH_TCL_VER - Like WITH_TCL_VER, but - per-port. - - - - USE_TCL_THREADS - Require a threaded build of - Tcl/Tk. - - - - USE_TK - The port depends on the - Tk library (not the wish - shell). Implies USE_TCL with the - same value. For more information see the description - of USE_TCL variable. - - - - USE_TK_BUILD - Analog to the USE_TCL_BUILD - variable. - - - - USE_TK_WRAPPER - Analog to the USE_TCL_WRAPPER - variable. - - - - WITH_TK_VER - Analog to the WITH_TCL_VER - variable and implies WITH_TCL_VER - of the same value. - - - -
- - A complete list of available variables can be found in - /usr/ports/Mk/bsd.tcl.mk. - - - - Using Emacs - - This section is yet to be written. - - - - Using Ruby - - - Useful Variables for Ports That Use Ruby - - - - - Variable - Description - - - - - USE_RUBY - The port requires Ruby. - - - - USE_RUBY_EXTCONF - The port uses extconf.rb to - configure. - - - - USE_RUBY_SETUP - The port uses setup.rb to - configure. - - - - RUBY_SETUP - Set to the alternative name of - setup.rb. Common value is - install.rb. - - - -
- - The following table shows the selected variables available - to port authors via the ports infrastructure. These variables - should be used to install files into their proper locations. - Use them in pkg-plist as much as - possible. These variables should not be redefined in the - port. - - - Selected Read-Only Variables for Ports That Use - Ruby - - - - - Variable - Description - Example value - - - - - - RUBY_PKGNAMEPREFIX - Used as a PKGNAMEPREFIX to - distinguish packages for different Ruby - versions. - ruby18- - - - - RUBY_VERSION - Full version of Ruby in the form of - x.y.z. - 1.8.2 - - - - RUBY_SITELIBDIR - Architecture independent libraries installation - path. - /usr/local/lib/ruby/site_ruby/1.8 - - - - RUBY_SITEARCHLIBDIR - Architecture dependent libraries installation - path. - /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6 - - - - RUBY_MODDOCDIR - Module documentation installation path. - /usr/local/share/doc/ruby18/patsy - - - - RUBY_MODEXAMPLESDIR - Module examples installation path. - /usr/local/share/examples/ruby18/patsy - - - -
- - A complete list of available variables can be found in - /usr/ports/Mk/bsd.ruby.mk. - - - - - Using SDL - - The USE_SDL variable is used to - autoconfigure the dependencies for ports which use an SDL - based library like devel/sdl12 - and graphics/sdl_image. - - The following SDL libraries for version 1.2 are recognized - at the moment: - - - - sdl: devel/sdl12 - - - - console: devel/sdl_console - - - - gfx: graphics/sdl_gfx - - - - image: graphics/sdl_image - - - - mixer: audio/sdl_mixer - - - - mm: devel/sdlmm - - - - net: net/sdl_net - - - - pango: x11-toolkits/sdl_pango - - - - sound: audio/sdl_sound - - - - ttf: graphics/sdl_ttf - - - - The following SDL libraries for version 2.0 are recognized - at the moment: - - - - sdl: devel/sdl20 - - - - gfx: graphics/sdl2_gfx - - - - image: graphics/sdl2_image - - - - mixer: audio/sdl2_mixer - - - - net: net/sdl2_net - - - - ttf: graphics/sdl2_ttf - - - - Therefore, if a port has a dependency on - net/sdl_net and - audio/sdl_mixer, - the syntax will be: - - USE_SDL= net mixer - - The dependency - devel/sdl12, which is - required by net/sdl_net - and audio/sdl_mixer, is - automatically added as well. - - If you use USE_SDL with entries using - SDL 1.2, it will automatically: - - - - Add a dependency on - sdl12-config to - BUILD_DEPENDS - - - - Add the variable SDL_CONFIG to - CONFIGURE_ENV - - - - Add the dependencies of the selected libraries to the - LIB_DEPENDS - - - - If you use USE_SDL with entries using - SDL 2.0, it will automatically: - - - - Add a dependency on - sdl2-config to - BUILD_DEPENDS - - - - Add the variable SDL2_CONFIG to - CONFIGURE_ENV - - - - Add the dependencies of the selected libraries to the - LIB_DEPENDS - - - - To check whether an SDL library is available, you can do - it with the WANT_SDL variable: - - WANT_SDL= yes + This recompiles the sources with a path relative to the + stage directory, and prepends the value of + PREFIX to the file name recorded in the + byte-compiled output file by -d. + -f is required to force recompilation, and + the :S;${PREFIX}/;; strips prefixes from + the value of the PYTHONPREFIX_SITELIBDIR + variable to make it relative to + PREFIX. + + Python 2.7 or newer is required for this. It does + not work with Python 2.6. + + + + Using <application>Tcl/Tk</application> + + The Ports Collection supports parallel installation of + multiple Tcl/Tk versions. Ports + should try to support at least the default + Tcl/Tk version and higher with the + USE_TCL and USE_TK + variables. It is possible to specify the desired version of + tcl with the + WITH_TCL_VER variable. + + + The Most Useful Variables for Ports That Use + <application>Tcl/Tk</application> + + + + + USE_TCL + The port depends on the + Tcl library (not the + shell). Minimal required version can be specified + with values such as 84+. Individual unsupported + versions can be specified with the + INVALID_TCL_VER variable. + + + + USE_TCL_BUILD + The port needs Tcl + only during the build time. + + + + USE_TCL_WRAPPER + Ports that require the + Tcl shell and do not + require a specific tclsh version + should use this new variable. The + tclsh wrapper is installed on the + system. The user can specify the desired + tcl shell to use. + + + + WITH_TCL_VER + User-defined variable that sets the desired + Tcl version. + + + + UNIQUENAME_WITH_TCL_VER + Like WITH_TCL_VER, but + per-port. + + + + USE_TCL_THREADS + Require a threaded build of + Tcl/Tk. + + + + USE_TK + The port depends on the + Tk library (not the wish + shell). Implies USE_TCL with the + same value. For more information see the description + of USE_TCL variable. + + + + USE_TK_BUILD + Analog to the USE_TCL_BUILD + variable. + + + + USE_TK_WRAPPER + Analog to the USE_TCL_WRAPPER + variable. + + + + WITH_TK_VER + Analog to the WITH_TCL_VER + variable and implies WITH_TCL_VER + of the same value. + + + +
+ + A complete list of available variables can be found in + /usr/ports/Mk/bsd.tcl.mk. + + + + Using Emacs + + This section is yet to be written. + + + + Using Ruby + + + Useful Variables for Ports That Use Ruby + + + + + Variable + Description + + + + + USE_RUBY + The port requires Ruby. + + + + USE_RUBY_EXTCONF + The port uses extconf.rb to + configure. + + + + USE_RUBY_SETUP + The port uses setup.rb to + configure. + + + + RUBY_SETUP + Set to the alternative name of + setup.rb. Common value is + install.rb. + + + +
+ + The following table shows the selected variables available + to port authors via the ports infrastructure. These variables + should be used to install files into their proper locations. + Use them in pkg-plist as much as + possible. These variables should not be redefined in the + port. + + + Selected Read-Only Variables for Ports That Use + Ruby + + + + + Variable + Description + Example value + + + + + + RUBY_PKGNAMEPREFIX + Used as a PKGNAMEPREFIX to + distinguish packages for different Ruby + versions. + ruby18- + + + + RUBY_VERSION + Full version of Ruby in the form of + x.y.z. + 1.8.2 + + + + RUBY_SITELIBDIR + Architecture independent libraries installation + path. + /usr/local/lib/ruby/site_ruby/1.8 + + + + RUBY_SITEARCHLIBDIR + Architecture dependent libraries installation + path. + /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6 + + + + RUBY_MODDOCDIR + Module documentation installation path. + /usr/local/share/doc/ruby18/patsy + + + + RUBY_MODEXAMPLESDIR + Module examples installation path. + /usr/local/share/examples/ruby18/patsy + + + +
+ + A complete list of available variables can be found in + /usr/ports/Mk/bsd.ruby.mk. + + + + Using SDL + + The USE_SDL variable is used to + autoconfigure the dependencies for ports which use an SDL + based library like devel/sdl12 + and graphics/sdl_image. + + The following SDL libraries for version 1.2 are recognized + at the moment: + + + + sdl: devel/sdl12 + + + + console: devel/sdl_console + + + + gfx: graphics/sdl_gfx + + + + image: graphics/sdl_image + + + + mixer: audio/sdl_mixer + + + + mm: devel/sdlmm + + + + net: net/sdl_net + + + + pango: x11-toolkits/sdl_pango + + + + sound: audio/sdl_sound + + + + ttf: graphics/sdl_ttf + + + + The following SDL libraries for version 2.0 are recognized + at the moment: + + + + sdl: devel/sdl20 + + + + gfx: graphics/sdl2_gfx + + + + image: graphics/sdl2_image + + + + mixer: audio/sdl2_mixer + + + + net: net/sdl2_net + + + + ttf: graphics/sdl2_ttf + + + + Therefore, if a port has a dependency on + net/sdl_net and + audio/sdl_mixer, + the syntax will be: + + USE_SDL= net mixer + + The dependency + devel/sdl12, which is + required by net/sdl_net + and audio/sdl_mixer, is + automatically added as well. + + If you use USE_SDL with entries using + SDL 1.2, it will automatically: + + + + Add a dependency on + sdl12-config to + BUILD_DEPENDS + + + + Add the variable SDL_CONFIG to + CONFIGURE_ENV + + + + Add the dependencies of the selected libraries to the + LIB_DEPENDS + + + + If you use USE_SDL with entries using + SDL 2.0, it will automatically: + + + + Add a dependency on + sdl2-config to + BUILD_DEPENDS + + + + Add the variable SDL2_CONFIG to + CONFIGURE_ENV + + + + Add the dependencies of the selected libraries to the + LIB_DEPENDS + + + + To check whether an SDL library is available, you can do + it with the WANT_SDL variable: + + WANT_SDL= yes .include <bsd.port.pre.mk> @@ -3117,429 +3115,429 @@ USE_SDL+= mixer .endif .include <bsd.port.post.mk> - + - - Using <application>wxWidgets</application> + + Using <application>wxWidgets</application> - This section describes the status of the - wxWidgets libraries in the ports - tree and its integration with the ports system. + This section describes the status of the + wxWidgets libraries in the ports + tree and its integration with the ports system. - - Introduction + + Introduction - There are many versions of the - wxWidgets libraries which - conflict between them (install files under the same name). - In the ports tree this problem has been solved by installing - each version under a different name using version number - suffixes. + There are many versions of the + wxWidgets libraries which + conflict between them (install files under the same name). + In the ports tree this problem has been solved by installing + each version under a different name using version number + suffixes. - The obvious disadvantage of this is that each - application has to be modified to find the expected version. - Fortunately, most of the applications call the - wx-config script to determine the - necessary compiler and linker flags. The script is named - differently for every available version. Majority of - applications respect an environment variable, or accept a - configure argument, to specify which - wx-config script to call. Otherwise they - have to be patched. - + The obvious disadvantage of this is that each + application has to be modified to find the expected version. + Fortunately, most of the applications call the + wx-config script to determine the + necessary compiler and linker flags. The script is named + differently for every available version. Majority of + applications respect an environment variable, or accept a + configure argument, to specify which + wx-config script to call. Otherwise they + have to be patched. + - - Version Selection + + Version Selection - To make your port use a specific version of - wxWidgets there are two variables - available for defining (if only one is defined the other - will be set to a default value): + To make your port use a specific version of + wxWidgets there are two variables + available for defining (if only one is defined the other + will be set to a default value): - - Variables to Select - <application>wxWidgets</application> Versions +
+ Variables to Select + <application>wxWidgets</application> Versions - - - - Variable - Description - Default value - - + + + + Variable + Description + Default value + + - - - USE_WX - List of versions the port can use - All available versions - + + + USE_WX + List of versions the port can use + All available versions + - - USE_WX_NOT - List of versions the port can not use - None - - - -
+ + USE_WX_NOT + List of versions the port can not use + None + + + + - The following is a list of available - wxWidgets versions and the - corresponding ports in the tree: + The following is a list of available + wxWidgets versions and the + corresponding ports in the tree: - - Available <application>wxWidgets</application> - Versions +
+ Available <application>wxWidgets</application> + Versions - - - - Version - Port - - + + + + Version + Port + + - - - 2.4 - x11-toolkits/wxgtk24 - + + + 2.4 + x11-toolkits/wxgtk24 + - - 2.6 - x11-toolkits/wxgtk26 - + + 2.6 + x11-toolkits/wxgtk26 + - - 2.8 - x11-toolkits/wxgtk28 - - - -
+ + 2.8 + x11-toolkits/wxgtk28 + + + + - - The versions starting from 2.5 also - come in Unicode version and are installed by a slave port - named like the normal one plus a - -unicode suffix, but this can be - handled with variables (see - ). - + + The versions starting from 2.5 also + come in Unicode version and are installed by a slave port + named like the normal one plus a + -unicode suffix, but this can be + handled with variables (see + ). + - The variables in can - be set to one or more of the following combinations - separated by spaces: + The variables in can + be set to one or more of the following combinations + separated by spaces: - - <application>wxWidgets</application> Version - Specifications +
+ <application>wxWidgets</application> Version + Specifications - - - - Description - Example - - + + + + Description + Example + + - - - Single version - 2.4 - + + + Single version + 2.4 + - - Ascending range - 2.4+ - + + Ascending range + 2.4+ + - - Descending range - 2.6- - + + Descending range + 2.6- + - - Full range (must be ascending) - 2.4-2.6 - - - -
+ + Full range (must be ascending) + 2.4-2.6 + + + + - There are also some variables to select the preferred - versions from the available ones. They can be set to a list - of versions, the first ones will have higher - priority. + There are also some variables to select the preferred + versions from the available ones. They can be set to a list + of versions, the first ones will have higher + priority. - - Variables to Select Preferred - <application>wxWidgets</application> Versions +
+ Variables to Select Preferred + <application>wxWidgets</application> Versions - - - - Name - Designed for - - + + + + Name + Designed for + + - - - WANT_WX_VER - the port - + + + WANT_WX_VER + the port + - - WITH_WX_VER - the user - - - -
- + + WITH_WX_VER + the user + + + + + - - Component Selection + + Component Selection - There are other applications that, while not being - wxWidgets libraries, are related - to them. These applications can be specified in the - WX_COMPS variable. The following - components are available: + There are other applications that, while not being + wxWidgets libraries, are related + to them. These applications can be specified in the + WX_COMPS variable. The following + components are available: - - Available <application>wxWidgets</application> - Components +
+ Available <application>wxWidgets</application> + Components - - - - Name - Description - Version restriction - - + + + + Name + Description + Version restriction + + - - - wx - main library - none - + + + wx + main library + none + - - contrib - contributed libraries - none - + + contrib + contributed libraries + none + - - python - wxPython - (Python bindings) - 2.4-2.6 - + + python + wxPython + (Python bindings) + 2.4-2.6 + - - mozilla - wxMozilla - 2.4 - + + mozilla + wxMozilla + 2.4 + - - svg - wxSVG - 2.6 - - - -
+ + svg + wxSVG + 2.6 + + + + - The dependency type can be selected for each component - by adding a suffix separated by a semicolon. If not present - then a default type will be used (see - ). The following types - are available: + The dependency type can be selected for each component + by adding a suffix separated by a semicolon. If not present + then a default type will be used (see + ). The following types + are available: - - Available <application>wxWidgets</application> - Dependency Types +
+ Available <application>wxWidgets</application> + Dependency Types - - - - Name - Description - - + + + + Name + Description + + - - - build - Component is required for building, equivalent - to BUILD_DEPENDS - + + + build + Component is required for building, equivalent + to BUILD_DEPENDS + - - run - Component is required for running, equivalent - to RUN_DEPENDS - + + run + Component is required for running, equivalent + to RUN_DEPENDS + - - lib - Component is required for building and running, - equivalent to LIB_DEPENDS - - - -
+ + lib + Component is required for building and running, + equivalent to LIB_DEPENDS + + + + - The default values for the components are detailed in - the following table: + The default values for the components are detailed in + the following table: - - Default <application>wxWidgets</application> - Dependency Types +
+ Default <application>wxWidgets</application> + Dependency Types - - - - Component - Dependency type - - + + + + Component + Dependency type + + - - - wx - lib - + + + wx + lib + - - contrib - lib - + + contrib + lib + - - python - run - + + python + run + - - mozilla - lib - + + mozilla + lib + - - svg - lib - - - -
+ + svg + lib + + + + - - Selecting <application>wxWidgets</application> - Components + + Selecting <application>wxWidgets</application> + Components - The following fragment corresponds to a port which - uses wxWidgets version - 2.4 and its contributed - libraries. + The following fragment corresponds to a port which + uses wxWidgets version + 2.4 and its contributed + libraries. - USE_WX= 2.4 + USE_WX= 2.4 WX_COMPS= wx contrib - - + + - - Unicode + + Unicode - The wxWidgets library - supports Unicode since version 2.5. In - the ports tree both versions are available and can be - selected with the following variables: + The wxWidgets library + supports Unicode since version 2.5. In + the ports tree both versions are available and can be + selected with the following variables: - - Variables to Select Unicode in - <application>wxWidgets</application> - Versions +
+ Variables to Select Unicode in + <application>wxWidgets</application> + Versions - - - - Variable - Description - Designed for - - + + + + Variable + Description + Designed for + + - - - WX_UNICODE - The port works only with - the Unicode version - the port - + + + WX_UNICODE + The port works only with + the Unicode version + the port + - - WANT_UNICODE - The port works with both versions but prefers - the Unicode one - the port - + + WANT_UNICODE + The port works with both versions but prefers + the Unicode one + the port + - - WITH_UNICODE - The port will use the Unicode version - the user - + + WITH_UNICODE + The port will use the Unicode version + the user + - - WITHOUT_UNICODE - The port will use the normal version if - supported (when WX_UNICODE is not - defined) - the user - - - -
+ + WITHOUT_UNICODE + The port will use the normal version if + supported (when WX_UNICODE is not + defined) + the user + + + + - - Do not use WX_UNICODE for ports - that can use both Unicode and normal versions. If you - want the port to use Unicode by default define - WANT_UNICODE instead. - - + + Do not use WX_UNICODE for ports + that can use both Unicode and normal versions. If you + want the port to use Unicode by default define + WANT_UNICODE instead. + + - - Detecting Installed Versions + + Detecting Installed Versions - To detect an installed version you have to define - WANT_WX. If you do not set it to a - specific version then the components will have a version - suffix. The HAVE_WX variable will be - filled after detection. + To detect an installed version you have to define + WANT_WX. If you do not set it to a + specific version then the components will have a version + suffix. The HAVE_WX variable will be + filled after detection. - - Detecting Installed - <application>wxWidgets</application> Versions and - Components + + Detecting Installed + <application>wxWidgets</application> Versions and + Components - The following fragment can be used in a port that uses - wxWidgets if it is installed, - or an option is selected. + The following fragment can be used in a port that uses + wxWidgets if it is installed, + or an option is selected. - WANT_WX= yes + WANT_WX= yes .include <bsd.port.pre.mk> @@ -3548,13 +3546,13 @@ USE_WX= 2.4 CONFIGURE_ARGS+= --enable-wx .endif - The following fragment can be used in a port that - enables wxPython support if it - is installed or if an option is selected, in addition to - wxWidgets, both version - 2.6. + The following fragment can be used in a port that + enables wxPython support if it + is installed or if an option is selected, in addition to + wxWidgets, both version + 2.6. - USE_WX= 2.6 + USE_WX= 2.6 WX_COMPS= wx WANT_WX= 2.6 @@ -3564,90 +3562,90 @@ WANT_WX= 2.6 WX_COMPS+= python CONFIGURE_ARGS+= --enable-wxpython .endif - - + + - - Defined Variables + + Defined Variables - The following variables are available in the port (after - defining one from - ). + The following variables are available in the port (after + defining one from + ). - - Variables Defined for Ports That Use - <application>wxWidgets</application> +
+ Variables Defined for Ports That Use + <application>wxWidgets</application> - - - - Name - Description - - + + + + Name + Description + + - - - WX_CONFIG - The path to the - wxWidgets - wx-config script (with different - name) - + + + WX_CONFIG + The path to the + wxWidgets + wx-config script (with different + name) + - - WXRC_CMD - The path to the - wxWidgets - wxrc program (with different - name) - + + WXRC_CMD + The path to the + wxWidgets + wxrc program (with different + name) + - - WX_VERSION - The wxWidgets - version that is going to be used (e.g., - 2.6) - + + WX_VERSION + The wxWidgets + version that is going to be used (e.g., + 2.6) + - - WX_UNICODE - If not defined but Unicode is going to be used - then it will be defined - - - -
- + + WX_UNICODE + If not defined but Unicode is going to be used + then it will be defined + + + + + - - Processing in - <filename>bsd.port.pre.mk</filename> + + Processing in + <filename>bsd.port.pre.mk</filename> - If you need to use the variables for running commands - right after including bsd.port.pre.mk - you need to define WX_PREMK. + If you need to use the variables for running commands + right after including bsd.port.pre.mk + you need to define WX_PREMK. - - If you define WX_PREMK, then the - version, dependencies, components and defined variables - will not change if you modify the - wxWidgets port variables - after including - bsd.port.pre.mk. - + + If you define WX_PREMK, then the + version, dependencies, components and defined variables + will not change if you modify the + wxWidgets port variables + after including + bsd.port.pre.mk. + - - Using <application>wxWidgets</application> Variables - in Commands + + Using <application>wxWidgets</application> Variables + in Commands - The following fragment illustrates the use of - WX_PREMK by running the - wx-config script to obtain the full - version string, assign it to a variable and pass it to the - program. + The following fragment illustrates the use of + WX_PREMK by running the + wx-config script to obtain the full + version string, assign it to a variable and pass it to the + program. - USE_WX= 2.4 + USE_WX= 2.4 WX_PREMK= yes .include <bsd.port.pre.mk> @@ -3657,397 +3655,397 @@ VER_STR!= ${WX_CONFIG} --release PLIST_SUB+= VERSION="${VER_STR}" .endif - + - - The wxWidgets variables can - be safely used in commands when they are inside targets - without the need of WX_PREMK. - - + + The wxWidgets variables can + be safely used in commands when they are inside targets + without the need of WX_PREMK. + + - - Additional <command>configure</command> - Arguments + + Additional <command>configure</command> + Arguments - Some GNU configure scripts can not - find wxWidgets with just the - WX_CONFIG environment variable set, - requiring additional arguments. The - WX_CONF_ARGS variable can be used for - provide them. + Some GNU configure scripts can not + find wxWidgets with just the + WX_CONFIG environment variable set, + requiring additional arguments. The + WX_CONF_ARGS variable can be used for + provide them. - - Legal Values for - <varname>WX_CONF_ARGS</varname> +
+ Legal Values for + <varname>WX_CONF_ARGS</varname> - - - - Possible value - Resulting argument - - + + + + Possible value + Resulting argument + + - - - absolute - --with-wx-config=${WX_CONFIG} - + + + absolute + --with-wx-config=${WX_CONFIG} + - - relative - --with-wx=${LOCALBASE} - --with-wx-config=${WX_CONFIG:T} - - - -
- - + + relative + --with-wx=${LOCALBASE} + --with-wx-config=${WX_CONFIG:T} + + + + + + - - Using <application>Lua</application> + + Using <application>Lua</application> - This section describes the status of the - Lua libraries in the ports tree and - its integration with the ports system. + This section describes the status of the + Lua libraries in the ports tree and + its integration with the ports system. - - Introduction + + Introduction - There are many versions of the - Lua libraries and corresponding - interpreters, which conflict between them (install files - under the same name). In the ports tree this problem has - been solved by installing each version under a different - name using version number suffixes. + There are many versions of the + Lua libraries and corresponding + interpreters, which conflict between them (install files + under the same name). In the ports tree this problem has + been solved by installing each version under a different + name using version number suffixes. - The obvious disadvantage of this is that each - application has to be modified to find the expected version. - But it can be solved by adding some additional flags to the - compiler and linker. - + The obvious disadvantage of this is that each + application has to be modified to find the expected version. + But it can be solved by adding some additional flags to the + compiler and linker. + - - Version Selection + + Version Selection - To make your port use a specific version of - Lua there are two variables - available for defining (if only one is defined the other - will be set to a default value): + To make your port use a specific version of + Lua there are two variables + available for defining (if only one is defined the other + will be set to a default value): - - Variables to Select <application>Lua</application> - Versions +
+ Variables to Select <application>Lua</application> + Versions - - - - Variable - Description - Default value - - + + + + Variable + Description + Default value + + - - - USE_LUA - List of versions the port can use - All available versions - + + + USE_LUA + List of versions the port can use + All available versions + - - USE_LUA_NOT - List of versions the port can not use - None - - - -
+ + USE_LUA_NOT + List of versions the port can not use + None + + + + - The following is a list of available - Lua versions and the - corresponding ports in the tree: + The following is a list of available + Lua versions and the + corresponding ports in the tree: - - Available <application>Lua</application> - Versions +
+ Available <application>Lua</application> + Versions - - - - Version - Port - - + + + + Version + Port + + - - - 4.0 - lang/lua4 - + + + 4.0 + lang/lua4 + - - 5.0 - lang/lua50 - + + 5.0 + lang/lua50 + - - 5.1 - lang/lua - - - -
+ + 5.1 + lang/lua + + + + - The variables in can - be set to one or more of the following combinations - separated by spaces: + The variables in can + be set to one or more of the following combinations + separated by spaces: - - <application>Lua</application> Version - Specifications +
+ <application>Lua</application> Version + Specifications - - - - Description - Example - - + + + + Description + Example + + - - - Single version - 4.0 - + + + Single version + 4.0 + - - Ascending range - 5.0+ - + + Ascending range + 5.0+ + - - Descending range - 5.0- - + + Descending range + 5.0- + - - Full range (must be ascending) - 5.0-5.1 - - - -
+ + Full range (must be ascending) + 5.0-5.1 + + + + - There are also some variables to select the preferred - versions from the available ones. They can be set to a list - of versions, the first ones will have higher - priority. + There are also some variables to select the preferred + versions from the available ones. They can be set to a list + of versions, the first ones will have higher + priority. - - Variables to Select Preferred - <application>Lua</application> Versions +
+ Variables to Select Preferred + <application>Lua</application> Versions - - - - Name - Designed for - - + + + + Name + Designed for + + - - - WANT_LUA_VER - the port - + + + WANT_LUA_VER + the port + - - WITH_LUA_VER - the user - - - -
+ + WITH_LUA_VER + the user + + + + - - Selecting the <application>Lua</application> - Version + + Selecting the <application>Lua</application> + Version - The following fragment is from a port which can use - Lua version - 5.0 or 5.1, and uses - 5.0 by default. It can be overridden - by the user with WITH_LUA_VER. + The following fragment is from a port which can use + Lua version + 5.0 or 5.1, and uses + 5.0 by default. It can be overridden + by the user with WITH_LUA_VER. - USE_LUA= 5.0-5.1 + USE_LUA= 5.0-5.1 WANT_LUA_VER= 5.0 - - + + - - Component Selection + + Component Selection - There are other applications that, while not being - Lua libraries, are related to - them. These applications can be specified in the - LUA_COMPS variable. The following - components are available: + There are other applications that, while not being + Lua libraries, are related to + them. These applications can be specified in the + LUA_COMPS variable. The following + components are available: - - Available <application>Lua</application> - Components +
+ Available <application>Lua</application> + Components - - - - Name - Description - Version restriction - - + + + + Name + Description + Version restriction + + - - - lua - main library - none - + + + lua + main library + none + - - tolua - Library for accessing C/C++ code - 4.0-5.0 - + + tolua + Library for accessing C/C++ code + 4.0-5.0 + - - ruby - Ruby bindings - 4.0-5.0 - - - -
+ + ruby + Ruby bindings + 4.0-5.0 + + + + - - There are more components but they are modules for the - interpreter, not used by applications (only by other - modules). - + + There are more components but they are modules for the + interpreter, not used by applications (only by other + modules). + - The dependency type can be selected for each component - by adding a suffix separated by a semicolon. If not present - then a default type will be used (see - ). The following types - are available: + The dependency type can be selected for each component + by adding a suffix separated by a semicolon. If not present + then a default type will be used (see + ). The following types + are available: - - Available <application>Lua</application> Dependency - Types +
+ Available <application>Lua</application> Dependency + Types - - - - Name - Description - - + + + + Name + Description + + - - - build - Component is required for building, equivalent - to BUILD_DEPENDS - + + + build + Component is required for building, equivalent + to BUILD_DEPENDS + - - run - Component is required for running, equivalent - to RUN_DEPENDS - + + run + Component is required for running, equivalent + to RUN_DEPENDS + - - lib - Component is required for building and running, - equivalent to LIB_DEPENDS - - - -
+ + lib + Component is required for building and running, + equivalent to LIB_DEPENDS + + + + - The default values for the components are detailed in - the following table: + The default values for the components are detailed in + the following table: - - Default <application>Lua</application> Dependency - Types +
+ Default <application>Lua</application> Dependency + Types - - - - Component - Dependency type - - + + + + Component + Dependency type + + - - - lua - lib for - 4.0-5.0 (shared) and - build for 5.1 - (static) - + + + lua + lib for + 4.0-5.0 (shared) and + build for 5.1 + (static) + - - tolua - build (static) - + + tolua + build (static) + - - ruby - lib (shared) - - - -
+ + ruby + lib (shared) + + + + - - Selecting <application>Lua</application> - Components + + Selecting <application>Lua</application> + Components - The following fragment corresponds to a port which - uses Lua version - 4.0 and its - Ruby bindings. + The following fragment corresponds to a port which + uses Lua version + 4.0 and its + Ruby bindings. - USE_LUA= 4.0 + USE_LUA= 4.0 LUA_COMPS= lua ruby - - + + - - Detecting Installed Versions + + Detecting Installed Versions - To detect an installed version you have to define - WANT_LUA. If you do not set it to a - specific version then the components will have a version - suffix. The HAVE_LUA variable will be - filled after detection. + To detect an installed version you have to define + WANT_LUA. If you do not set it to a + specific version then the components will have a version + suffix. The HAVE_LUA variable will be + filled after detection. - - Detecting Installed <application>Lua</application> - Versions and Components + + Detecting Installed <application>Lua</application> + Versions and Components - The following fragment can be used in a port that uses - Lua if it is installed, or an - option is selected. + The following fragment can be used in a port that uses + Lua if it is installed, or an + option is selected. - WANT_LUA= yes + WANT_LUA= yes .include <bsd.port.pre.mk> @@ -4056,13 +4054,13 @@ USE_LUA= 5.0-5.1 CONFIGURE_ARGS+= --enable-lua5 .endif - The following fragment can be used in a port that - enables tolua support if it is - installed or if an option is selected, in addition to - Lua, both version - 4.0. + The following fragment can be used in a port that + enables tolua support if it is + installed or if an option is selected, in addition to + Lua, both version + 4.0. - USE_LUA= 4.0 + USE_LUA= 4.0 LUA_COMPS= lua WANT_LUA= 4.0 @@ -4072,165 +4070,165 @@ WANT_LUA= 4.0 LUA_COMPS+= tolua CONFIGURE_ARGS+= --enable-tolua .endif - - + + - - Defined Variables + + Defined Variables - The following variables are available in the port (after - defining one from - ). + The following variables are available in the port (after + defining one from + ). - - Variables Defined for Ports That Use - <application>Lua</application> +
+ Variables Defined for Ports That Use + <application>Lua</application> - - - - Name - Description - - + + + + Name + Description + + - - - LUA_VER - The Lua version that - is going to be used (e.g., - 5.1) - + + + LUA_VER + The Lua version that + is going to be used (e.g., + 5.1) + - - LUA_VER_SH - The Lua shared - library major version (e.g., - 1) - + + LUA_VER_SH + The Lua shared + library major version (e.g., + 1) + - - LUA_VER_STR - The Lua version - without the dots (e.g., - 51) - + + LUA_VER_STR + The Lua version + without the dots (e.g., + 51) + - - LUA_PREFIX - The prefix where Lua - (and components) is installed - + + LUA_PREFIX + The prefix where Lua + (and components) is installed + - - LUA_SUBDIR - The directory under - ${PREFIX}/bin, - ${PREFIX}/share and - ${PREFIX}/lib where - Lua is installed - + + LUA_SUBDIR + The directory under + ${PREFIX}/bin, + ${PREFIX}/share and + ${PREFIX}/lib where + Lua is installed + - - LUA_INCDIR - The directory where - Lua and - tolua header files are - installed - + + LUA_INCDIR + The directory where + Lua and + tolua header files are + installed + - - LUA_LIBDIR - The directory where - Lua and - tolua libraries are - installed - + + LUA_LIBDIR + The directory where + Lua and + tolua libraries are + installed + - - LUA_MODLIBDIR - The directory where - Lua module libraries - (.so) are installed - + + LUA_MODLIBDIR + The directory where + Lua module libraries + (.so) are installed + - - LUA_MODSHAREDIR - The directory where - Lua modules - (.lua) are installed - + + LUA_MODSHAREDIR + The directory where + Lua modules + (.lua) are installed + - - LUA_PKGNAMEPREFIX - The package name prefix used by - Lua modules - + + LUA_PKGNAMEPREFIX + The package name prefix used by + Lua modules + - - LUA_CMD - The path to the Lua - interpreter - + + LUA_CMD + The path to the Lua + interpreter + - - LUAC_CMD - The path to the Lua - compiler - + + LUAC_CMD + The path to the Lua + compiler + - - TOLUA_CMD - The path to the - tolua program - - - -
+ + TOLUA_CMD + The path to the + tolua program + + + + - - Telling the Port Where to Find - <application>Lua</application> + + Telling the Port Where to Find + <application>Lua</application> - The following fragment shows how to tell a port that - uses a configure script where the - Lua header files and libraries - are. + The following fragment shows how to tell a port that + uses a configure script where the + Lua header files and libraries + are. - USE_LUA= 4.0 + USE_LUA= 4.0 GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}" - - + + - - Processing in - <filename>bsd.port.pre.mk</filename> + + Processing in + <filename>bsd.port.pre.mk</filename> - If you need to use the variables for running commands - right after including bsd.port.pre.mk - you need to define LUA_PREMK. + If you need to use the variables for running commands + right after including bsd.port.pre.mk + you need to define LUA_PREMK. - - If you define LUA_PREMK, then the - version, dependencies, components and defined variables - will not change if you modify the - Lua port variables - after including - bsd.port.pre.mk. - + + If you define LUA_PREMK, then the + version, dependencies, components and defined variables + will not change if you modify the + Lua port variables + after including + bsd.port.pre.mk. + - - Using <application>Lua</application> Variables in - Commands + + Using <application>Lua</application> Variables in + Commands - The following fragment illustrates the use of - LUA_PREMK by running the - Lua interpreter to obtain the - full version string, assign it to a variable and pass it - to the program. + The following fragment illustrates the use of + LUA_PREMK by running the + Lua interpreter to obtain the + full version string, assign it to a variable and pass it + to the program. - USE_LUA= 5.0 + USE_LUA= 5.0 LUA_PREMK= yes .include <bsd.port.pre.mk> @@ -4240,144 +4238,144 @@ VER_STR!= ${LUA_CMD} -v CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}" .endif - + - - The Lua variables can be - safely used in commands when they are inside targets - without the need of LUA_PREMK. - - - + + The Lua variables can be + safely used in commands when they are inside targets + without the need of LUA_PREMK. + + + - - Using <command>iconv</command> + + Using <command>iconv</command> - After 2013-10-08 (254273), - &os;  10-CURRENT and newer versions have a native - iconv in the operating system. On earlier - versions, converters/libiconv - was used as a dependency. + After 2013-10-08 (254273), + &os;  10-CURRENT and newer versions have a native + iconv in the operating system. On earlier + versions, converters/libiconv + was used as a dependency. - For software that needs iconv, define - USES=iconv. &os; versions before - 10-CURRENT on 2013-08-13 (254273) do - not have a native iconv. On these earlier - versions, a dependency on - converters/libiconv will be - added automatically. + For software that needs iconv, define + USES=iconv. &os; versions before + 10-CURRENT on 2013-08-13 (254273) do + not have a native iconv. On these earlier + versions, a dependency on + converters/libiconv will be + added automatically. - When a port defines USES=iconv, these - variables will be available: + When a port defines USES=iconv, these + variables will be available: - - - - - Variable name - Purpose - Value before &os; 10-CURRENT - 254273 (2013-08-13) - Value after &os; 10-CURRENT - 254273 (2013-08-13) - - + + + + + Variable name + Purpose + Value before &os; 10-CURRENT + 254273 (2013-08-13) + Value after &os; 10-CURRENT + 254273 (2013-08-13) + + - - - ICONV_CMD - Directory where the iconv - binary resides - ${LOCALBASE}/bin/iconv - /usr/bin/iconv - + + + ICONV_CMD + Directory where the iconv + binary resides + ${LOCALBASE}/bin/iconv + /usr/bin/iconv + - - ICONV_LIB - ld argument to link to - libiconv (if needed) - -liconv - (empty) - + + ICONV_LIB + ld argument to link to + libiconv (if needed) + -liconv + (empty) + - - ICONV_PREFIX - Directory where the iconv - implementation resides (useful for configure - scripts) - ${LOCALBASE} - /usr - + + ICONV_PREFIX + Directory where the iconv + implementation resides (useful for configure + scripts) + ${LOCALBASE} + /usr + - - ICONV_CONFIGURE_ARG - Preconstructed configure argument for - configure scripts - --with-libiconv-prefix=${LOCALBASE} - (empty) - + + ICONV_CONFIGURE_ARG + Preconstructed configure argument for + configure scripts + --with-libiconv-prefix=${LOCALBASE} + (empty) + - - ICONV_CONFIGURE_BASE - Preconstructed configure argument for - configure scripts - --with-libiconv=${LOCALBASE} - (empty) - - - - + + ICONV_CONFIGURE_BASE + Preconstructed configure argument for + configure scripts + --with-libiconv=${LOCALBASE} + (empty) + + + + - These two examples automatically populate the variables - with the correct value for systems using - converters/libiconv or the - native iconv respectively: + These two examples automatically populate the variables + with the correct value for systems using + converters/libiconv or the + native iconv respectively: - - Simple <command>iconv</command> Usage + + Simple <command>iconv</command> Usage - USES= iconv + USES= iconv LDFLAGS+= -L${LOCALBASE}/lib ${ICONV_LIB} - + - - <command>iconv</command> Usage with - <command>configure</command> + + <command>iconv</command> Usage with + <command>configure</command> - USES= iconv + USES= iconv CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG} - + - As shown above, ICONV_LIB is empty when - a native iconv is present. This can be - used to detect the native iconv and respond - appropriately. + As shown above, ICONV_LIB is empty when + a native iconv is present. This can be + used to detect the native iconv and respond + appropriately. - Sometimes a program has an ld argument - or search path hardcoded in a Makefile or - configure script. This approach can be used to solve that - problem: + Sometimes a program has an ld argument + or search path hardcoded in a Makefile or + configure script. This approach can be used to solve that + problem: - - Fixing Hardcoded <literal>-liconv</literal> + + Fixing Hardcoded <literal>-liconv</literal> - USES= iconv + USES= iconv post-patch: @${REINPLACE_CMD} -e 's/-liconv/${ICONV_LIB}/' ${WRKSRC}/Makefile - + - In some cases it is necessary to set alternate values or - perform operations depending on whether there is a native - iconv. - bsd.port.pre.mk must be included before - testing the value of ICONV_LIB: + In some cases it is necessary to set alternate values or + perform operations depending on whether there is a native + iconv. + bsd.port.pre.mk must be included before + testing the value of ICONV_LIB: - - Checking for Native <command>iconv</command> - Availability + + Checking for Native <command>iconv</command> + Availability - USES= iconv + USES= iconv .include <bsd.port.pre.mk> @@ -4388,280 +4386,280 @@ post-patch: .endif .include <bsd.port.post.mk> - - + + - - Using Xfce + + Using Xfce - The USE_XFCE variable is used to - autoconfigure the dependencies for ports which use an Xfce - based library or application like - x11-toolkits/libxfce4gui - and x11-wm/xfce4-panel. + The USE_XFCE variable is used to + autoconfigure the dependencies for ports which use an Xfce + based library or application like + x11-toolkits/libxfce4gui + and x11-wm/xfce4-panel. - The following Xfce libraries and applications are - recognized at the moment: + The following Xfce libraries and applications are + recognized at the moment: - - - libexo: x11/libexo - + + + libexo: x11/libexo + - - libgui: x11-toolkits/libxfce4gui - + + libgui: x11-toolkits/libxfce4gui + - - libutil: x11/libxfce4util - + + libutil: x11/libxfce4util + - - libmcs: x11/libxfce4mcs - + + libmcs: x11/libxfce4mcs + - - mcsmanager: sysutils/xfce4-mcs-manager - + + mcsmanager: sysutils/xfce4-mcs-manager + - - panel: x11-wm/xfce4-panel - + + panel: x11-wm/xfce4-panel + - - thunar: x11-fm/thunar - + + thunar: x11-fm/thunar + - - wm: x11-wm/xfce4-wm - + + wm: x11-wm/xfce4-wm + - - xfdev: dev/xfce4-dev-tools - - + + xfdev: dev/xfce4-dev-tools + + - The following additional parameters are recognized: + The following additional parameters are recognized: - - - configenv: Use this if your port requires a special - modified CONFIGURE_ENV to find its - required libraries. + + + configenv: Use this if your port requires a special + modified CONFIGURE_ENV to find its + required libraries. - -I${LOCALBASE}/include -L${LOCALBASE}/lib + -I${LOCALBASE}/include -L${LOCALBASE}/lib - gets added to CPPFLAGS to - CONFIGURE_ENV. - - + gets added to CPPFLAGS to + CONFIGURE_ENV. + + - Therefore, if a port has a dependency on - sysutils/xfce4-mcs-manager - and requires the special CPPFLAGS in its configure - environment, the syntax will be: + Therefore, if a port has a dependency on + sysutils/xfce4-mcs-manager + and requires the special CPPFLAGS in its configure + environment, the syntax will be: - USE_XFCE= mcsmanager configenv - + USE_XFCE= mcsmanager configenv + - - Using Mozilla + + Using Mozilla - - Variables for Ports That Use Mozilla +
+ Variables for Ports That Use Mozilla - - + + - - USE_GECKO - Gecko backend the port can handle. Possible - values: libxul - (libxul.so), - seamonkey - (libgtkembedmoz.so, deprecated, - should not be used any more). - + + USE_GECKO + Gecko backend the port can handle. Possible + values: libxul + (libxul.so), + seamonkey + (libgtkembedmoz.so, deprecated, + should not be used any more). + - - USE_FIREFOX - The port requires Firefox as a runtime - dependency. Possible values: yes - (get default version), 40, - 36, 35. Default - dependency is on version - 40. - + + USE_FIREFOX + The port requires Firefox as a runtime + dependency. Possible values: yes + (get default version), 40, + 36, 35. Default + dependency is on version + 40. + - - USE_FIREFOX_BUILD - The port requires Firefox as a buildtime - dependency. Possible values: see USE_FIREFOX. This - automatically sets USE_FIREFOX and assigns the same - value. - + + USE_FIREFOX_BUILD + The port requires Firefox as a buildtime + dependency. Possible values: see USE_FIREFOX. This + automatically sets USE_FIREFOX and assigns the same + value. + - - USE_SEAMONKEY - The port requires SeaMonkey as a runtime - dependency. Possible values: yes - (get default version), 20, - 11 (deprecated, should not be used - any more). Default dependency is on version - 20. - + + USE_SEAMONKEY + The port requires SeaMonkey as a runtime + dependency. Possible values: yes + (get default version), 20, + 11 (deprecated, should not be used + any more). Default dependency is on version + 20. + - - USE_SEAMONKEY_BUILD - The port requires SeaMonkey as a buildtime - dependency. Possible values: see USE_SEAMONKEY. This - automatically sets USE_SEAMONKEY and assigns the same - value. - + + USE_SEAMONKEY_BUILD + The port requires SeaMonkey as a buildtime + dependency. Possible values: see USE_SEAMONKEY. This + automatically sets USE_SEAMONKEY and assigns the same + value. + - - USE_THUNDERBIRD - The port requires Thunderbird as a runtime - dependency. Possible values: yes - (get default version), 31, - 30 (deprecated, should not be used - any more). Default dependency is on version - 31. - + + USE_THUNDERBIRD + The port requires Thunderbird as a runtime + dependency. Possible values: yes + (get default version), 31, + 30 (deprecated, should not be used + any more). Default dependency is on version + 31. + - - USE_THUNDERBIRD_BUILD - The port requires Thunderbird as a buildtime - dependency. Possible values: see USE_THUNDERBIRD. - This automatically sets USE_THUNDERBIRD and assigns - the same value. - - - -
+ + USE_THUNDERBIRD_BUILD + The port requires Thunderbird as a buildtime + dependency. Possible values: see USE_THUNDERBIRD. + This automatically sets USE_THUNDERBIRD and assigns + the same value. + + + + - A complete list of available variables can be found in - /usr/ports/Mk/bsd.gecko.mk. - + A complete list of available variables can be found in + /usr/ports/Mk/bsd.gecko.mk. + - - Using Databases + + Using Databases - - Variables for Ports Using Databases +
+ Variables for Ports Using Databases - - - - Variable - Means - - + + + + Variable + Means + + - - - USE_BDB - If variable is set to yes, - add dependency on - databases/db41 - port. The variable may also be set to values: 40, 41, - 42, 43, 44, 46, 47, 48, or 51. You can declare a - range of acceptable values, - USE_BDB=42+ will find the highest - installed version, and fall back to 42 if nothing else - is installed. - + + + USE_BDB + If variable is set to yes, + add dependency on + databases/db41 + port. The variable may also be set to values: 40, 41, + 42, 43, 44, 46, 47, 48, or 51. You can declare a + range of acceptable values, + USE_BDB=42+ will find the highest + installed version, and fall back to 42 if nothing else + is installed. + - - USE_MYSQL - If the variable is set to yes, - add a dependency on the databases/mysql55-client port. - An associated variable, - WANT_MYSQL_VER, may be set to - values such as 323, 40, 41, 50, 51, 52, 55, or - 60. - + + USE_MYSQL + If the variable is set to yes, + add a dependency on the databases/mysql55-client port. + An associated variable, + WANT_MYSQL_VER, may be set to + values such as 323, 40, 41, 50, 51, 52, 55, or + 60. + - - USE_PGSQL - If set to yes, add dependency - on databases/postgresql90-client - port. An associated variable, - WANT_PGSQL_VER, may be set to - values such as 83, 84, 90, 91 or 92. You can declare - a minimum or maximum value; - WANT_PGSQL_VER= - 90+ will cause the port to depend on a - minimum version of 9.0. - + + USE_PGSQL + If set to yes, add dependency + on databases/postgresql90-client + port. An associated variable, + WANT_PGSQL_VER, may be set to + values such as 83, 84, 90, 91 or 92. You can declare + a minimum or maximum value; + WANT_PGSQL_VER= + 90+ will cause the port to depend on a + minimum version of 9.0. + - - USE_SQLITE - If variable is set to yes, add - dependency on - databases/sqlite3 - port. The variable may also be set to values: 3, - 2. - - - -
+ + USE_SQLITE + If variable is set to yes, add + dependency on + databases/sqlite3 + port. The variable may also be set to values: 3, + 2. + + + + - More details are available in bsd.database.mk. - + More details are available in bsd.database.mk. + - - Starting and Stopping Services (<literal>rc</literal> - Scripts) + + Starting and Stopping Services (<literal>rc</literal> + Scripts) - rc.d scripts are used to start - services on system startup, and to give administrators a - standard way of stopping, starting and restarting the service. - Ports integrate into the system rc.d - framework. Details on its usage can be found in the - rc.d Handbook chapter. Detailed explanation of - the available commands is provided in &man.rc.8; and - &man.rc.subr.8;. Finally, there is - an - article on practical aspects of - rc.d scripting. + rc.d scripts are used to start + services on system startup, and to give administrators a + standard way of stopping, starting and restarting the service. + Ports integrate into the system rc.d + framework. Details on its usage can be found in the + rc.d Handbook chapter. Detailed explanation of + the available commands is provided in &man.rc.8; and + &man.rc.subr.8;. Finally, there is + an + article on practical aspects of + rc.d scripting. - One or more rc.d scripts can be - installed: + One or more rc.d scripts can be + installed: - USE_RC_SUBR= doormand + USE_RC_SUBR= doormand - Scripts must be placed in the files - subdirectory and a .in suffix must be added - to their filename. Standard SUB_LIST - expansions will be used for this file. Use of the - %%PREFIX%% and - %%LOCALBASE%% expansions is strongly - encouraged as well. More on SUB_LIST in - the relevant - section. + Scripts must be placed in the files + subdirectory and a .in suffix must be added + to their filename. Standard SUB_LIST + expansions will be used for this file. Use of the + %%PREFIX%% and + %%LOCALBASE%% expansions is strongly + encouraged as well. More on SUB_LIST in + the relevant + section. - As of &os; 6.1-RELEASE, local - rc.d scripts (including those installed - by ports) are included in the overall &man.rcorder.8; of the - base system. + As of &os; 6.1-RELEASE, local + rc.d scripts (including those installed + by ports) are included in the overall &man.rcorder.8; of the + base system. - Example simple rc.d script: + Example simple rc.d script: - #!/bin/sh + #!/bin/sh # $FreeBSD$ # @@ -4694,237 +4692,235 @@ command_args="-p $pidfile -f $doormand_config" run_rc_command "$1" - Unless there is a good reason to start the service - earlier all ports scripts should use + Unless there is a good reason to start the service + earlier all ports scripts should use - REQUIRE: LOGIN + REQUIRE: LOGIN - If the service runs as a particular user (other than root) - this is mandatory. + If the service runs as a particular user (other than root) + this is mandatory. - KEYWORD: shutdown + KEYWORD: shutdown - is included in the script above because the mythical port - we are using as an example starts a service, and should be - shut down cleanly when the system shuts down. If the script - is not starting a persistent service this is not - necessary. + is included in the script above because the mythical port + we are using as an example starts a service, and should be + shut down cleanly when the system shuts down. If the script + is not starting a persistent service this is not + necessary. - For optional configuration elements the "=" - style of default variable assignment is preferable to the - ":=" style here, since the former sets a default - value only if the variable is unset, and the latter sets one - if the variable is unset or null. A user - might very well include something like + For optional configuration elements the "=" + style of default variable assignment is preferable to the + ":=" style here, since the former sets a default + value only if the variable is unset, and the latter sets one + if the variable is unset or null. A user + might very well include something like - doormand_flags="" + doormand_flags="" - in their rc.conf.local file, and a - variable substitution using ":=" would - inappropriately override the user's intention. The - _enable variable is not optional, - and should use the ":" for the default. + in their rc.conf.local file, and a + variable substitution using ":=" would + inappropriately override the user's intention. The + _enable variable is not optional, + and should use the ":" for the default. - - Pre-Commit Checklist + + Pre-Commit Checklist - Before contributing a port with an - rc.d script, and more importantly, - before committing one, please consult the following - checklist to be sure that it is ready. + Before contributing a port with an + rc.d script, and more importantly, + before committing one, please consult the following + checklist to be sure that it is ready. - The devel/rclint - port can check for most of these, but it is not a - substitute for proper review. + The devel/rclint + port can check for most of these, but it is not a + substitute for proper review. - - - If this is a new file, does it have - .sh in the file name? If so that - should be changed to just file.in - since rc.d files may not end - with that extension. - + + + If this is a new file, does it have + .sh in the file name? If so that + should be changed to just file.in + since rc.d files may not end + with that extension. + - - Does the file have a - $FreeBSD$ tag? - + + Does the file have a + $FreeBSD$ tag? + - - Do the name of the file (minus - .in), the - PROVIDE line, and - $name - all match? The file name matching - PROVIDE makes debugging easier, - especially for &man.rcorder.8; issues. Matching the - file name and - $name - makes it easier to figure out which variables are - relevant in rc.conf[.local]. The - latter is also what you might call “policy” - for all new scripts, including those in the base - system. - + + Do the name of the file (minus + .in), the + PROVIDE line, and + $name + all match? The file name matching + PROVIDE makes debugging easier, + especially for &man.rcorder.8; issues. Matching the + file name and + $name + makes it easier to figure out which variables are + relevant in rc.conf[.local]. The + latter is also what you might call “policy” + for all new scripts, including those in the base + system. + - - Is the REQUIRE line set to - LOGIN? This is mandatory for scripts - that run as a non-root user. If it runs as root, is - there a good reason for it to run prior to - LOGIN? If not, it should run there - so that we can loosely group local scripts to a point in - &man.rcorder.8; after most everything in the base is - already running. - + + Is the REQUIRE line set to + LOGIN? This is mandatory for scripts + that run as a non-root user. If it runs as root, is + there a good reason for it to run prior to + LOGIN? If not, it should run there + so that we can loosely group local scripts to a point in + &man.rcorder.8; after most everything in the base is + already running. + - - Does the script start a persistent service? If so, - it should have KEYWORD: - shutdown. - + + Does the script start a persistent service? If so, + it should have KEYWORD: + shutdown. + - + + Make sure there is no + KEYWORD: &os; present. This has + not been necessary or desirable for years. It is also + an indication that the new script was copy/pasted from + an old script, so extra caution should be given to the + review. + - Make sure there is no - KEYWORD: &os; present. This has - not been necessary or desirable for years. It is also - an indication that the new script was copy/pasted from - an old script, so extra caution should be given to the - review. - + + If the script uses an interpreted language like + perl, python, or + ruby, make certain that + command_interpreter is set + appropriately. Otherwise, - - If the script uses an interpreted language like - perl, python, or - ruby, make certain that - command_interpreter is set - appropriately. Otherwise, + &prompt.root; service name stop - &prompt.root; service name stop + will probably not work properly. See + &man.service.8; for more information. + - will probably not work properly. See - &man.service.8; for more information. - + + Have all occurrences of + /usr/local been replaced with + %%PREFIX%%? + - - Have all occurrences of - /usr/local been replaced with - %%PREFIX%%? - + + Do the default variable assignments come after + load_rc_config? + - - Do the default variable assignments come after - load_rc_config? - + + Are there default assignments to empty strings? + They should be removed, but double-check that the option + is documented in the comments at the top of the + file. + - - Are there default assignments to empty strings? - They should be removed, but double-check that the option - is documented in the comments at the top of the - file. - + + Are things that are set in variables actually used + in the script? + - - Are things that are set in variables actually used - in the script? - + + Are options listed in the default + name_flags + things that are actually mandatory? If so, they should + be in command_args. The + option is a red flag (pardon the + pun) here, since it is usually the option to + “daemonize” the process, and therefore is + actually mandatory. + - - Are options listed in the default - name_flags - things that are actually mandatory? If so, they should - be in command_args. The - option is a red flag (pardon the - pun) here, since it is usually the option to - “daemonize” the process, and therefore is - actually mandatory. - + + The + name_flags + variable should never be included in + command_args (and vice versa, + although that error is less common). + - - The - name_flags - variable should never be included in - command_args (and vice versa, - although that error is less common). - + + Does the script execute any code unconditionally? + This is frowned on. Usually these things can/should be + dealt with through a + start_precmd. + - - Does the script execute any code unconditionally? - This is frowned on. Usually these things can/should be - dealt with through a - start_precmd. - + + All boolean tests should utilize the + checkyesno function. No + hand-rolled tests for [Yy][Ee][Ss], + etc. + - - All boolean tests should utilize the - checkyesno function. No - hand-rolled tests for [Yy][Ee][Ss], - etc. - + + If there is a loop (for example, waiting for + something to start) does it have a counter to terminate + the loop? We do not want the boot to be stuck forever + if there is an error. + - - If there is a loop (for example, waiting for - something to start) does it have a counter to terminate - the loop? We do not want the boot to be stuck forever - if there is an error. - + + Does the script create files or directories that + need specific permissions, for example, a + pid file that needs to be owned by + the user that runs the process? Rather than the + traditional &man.touch.1;/&man.chown.8;/&man.chmod.1; + routine, consider using &man.install.1; with the proper + command line arguments to do the whole procedure with + one step. + + + + - - Does the script create files or directories that - need specific permissions, for example, a - pid file that needs to be owned by - the user that runs the process? Rather than the - traditional &man.touch.1;/&man.chown.8;/&man.chmod.1; - routine, consider using &man.install.1; with the proper - command line arguments to do the whole procedure with - one step. - - - - + + Adding Users and Groups - - Adding Users and Groups + Some ports require a certain user to be on the installed + system. Choose a free UID from 50 to 999 and register it + either in ports/UIDs (for users) or in + ports/GIDs (for groups). Make sure you + do not use a UID already used by the system or other + ports. - Some ports require a certain user to be on the installed - system. Choose a free UID from 50 to 999 and register it - either in ports/UIDs (for users) or in - ports/GIDs (for groups). Make sure you - do not use a UID already used by the system or other - ports. + Please include a patch against these two files when you + require a new user or group to be created for your + port. - Please include a patch against these two files when you - require a new user or group to be created for your - port. + Then you can use USERS and + GROUPS variables in your + Makefile, and the user will be + automatically created when installing the port. - Then you can use USERS and - GROUPS variables in your - Makefile, and the user will be - automatically created when installing the port. - - USERS= pulse + USERS= pulse GROUPS= pulse pulse-access pulse-rt - The current list of reserved UIDs and GIDs can be found - in ports/UIDs and - ports/GIDs. - + The current list of reserved UIDs and GIDs can be found + in ports/UIDs and + ports/GIDs. + - - Ports That Rely on Kernel Sources + + Ports That Rely on Kernel Sources - Some ports (such as kernel loadable modules) need the - kernel source files so that the port can compile. Here is the - correct way to determine if the user has them - installed: + Some ports (such as kernel loadable modules) need the + kernel source files so that the port can compile. Here is the + correct way to determine if the user has them + installed: - USES= kmod - - Apart from this check, the kmod feature - takes care of most items that these ports need to take into - account. - - + USES= kmod + Apart from this check, the kmod feature + takes care of most items that these ports need to take into + account. + +