From owner-svn-doc-all@FreeBSD.ORG Sun Feb 16 03:25:23 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A39BA6C; Sun, 16 Feb 2014 03:25:23 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 125F6171B; Sun, 16 Feb 2014 03:25:23 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G3PNVl075668; Sun, 16 Feb 2014 03:25:23 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G3PM7E075667; Sun, 16 Feb 2014 03:25:22 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160325.s1G3PM7E075667@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 03:25:22 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43956 - head/en_US.ISO8859-1/books/porters-handbook/special X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:25:23 -0000 Author: wblock Date: Sun Feb 16 03:25:22 2014 New Revision: 43956 URL: http://svnweb.freebsd.org/changeset/doc/43956 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:09:35 2014 (r43955) +++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:25:22 2014 (r43956) @@ -4,3542 +4,3540 @@ $FreeBSD$ --> - + + + 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. + + + 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 ). + + 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 + + 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 + + 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: + + ${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. + + Ports that install kernel modules must prepend the + STAGEDIR variable to + their destination, by default + /boot/modules. + + + + 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. + + 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: + + 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. + + 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. + + 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 + + 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;. + + + In situations like this, the variables described in the + following sections can be set. + + + <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. + + 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 be set to a string + describing the reason why the package should not be + generated. + + + + <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. + + 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. + + + + <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. + + 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> + + 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. + + 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> + + 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> + + 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> + + 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. + - Special Considerations + + Examples - 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 - - 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: - - 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: - - 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. + The preferred way to state "the distfiles for this port + must be fetched manually" is as follows: - 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 - - 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. - - - - 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. - - 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: - - 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. - - 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. - - 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 - - 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;. - - - In situations like this, the variables described in the - following sections can be set. - - - <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. - - 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 be set to a string - describing the reason why the package should not be - generated. - - - - <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. - - 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. - - - - <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. - - 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> - - 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. - - 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> - - 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> - - 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> - - 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 - - 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. - - Note that this stanza must be preceded by an inclusion - of bsd.port.pre.mk. - - - - - Building Mechanisms - - - 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. - - 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> - - 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. - - 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'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 - - 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> - - - - - Variable - Means - - - - - - 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. - - - - CONFIGURE_ARGS - Additional arguments passed to - configure script. - - - - 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}. - - - -
- - - - Using <command>cmake</command> - - 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> - - - - - Variable - Means - - - - - - 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_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}. - - - -
- - - Variables the Users can define for - <command>cmake</command> builds - - - - - Variable - Means - - - - - - 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 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. - - - <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. - - USES= cmake:outsource -CMAKE_SOURCE_PATH= ${WRKSRC}/subproject - - - - - Using <command>scons</command> + This both informs the user, and sets the proper metadata + on the user's machine for use by automated programs. - If your port uses SCons, - define USE_SCONS=yes. + Note that this stanza must be preceded by an inclusion + of bsd.port.pre.mk. + + + + + Building Mechanisms + + + 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. + + 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> + + 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. + + 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'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 + + 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>scons</command> - - - - - Variable - Means - - - - - - SCONS_ARGS - Port specific SCons flags passed to the SCons - environment. - - - - SCONS_BUILDENV - Variables to be set in system - environment. - - - - SCONS_ENV - Variables to be set in SCons - environment. - - - - 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: - - env = Environment(**ARGUMENTS) - - It may be then modified with - env.Append and - env.Replace. - - - - - Using GNU Autotools - - *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***