16480 lines
527 KiB
XML
16480 lines
527 KiB
XML
<?xml version="1.0" encoding="ISO8859-1" standalone="no"?>
|
|
<!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook XML V4.2-Based Extension//EN"
|
|
"../../../share/sgml/freebsd42.dtd" [
|
|
<!ENTITY % entities PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Entity Set//EN" "../../share/sgml/entities.ent">
|
|
%entities;
|
|
]>
|
|
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
|
|
$FreeBSD$
|
|
-->
|
|
|
|
<book lang='en'>
|
|
<bookinfo>
|
|
<title>FreeBSD Porter's Handbook</title>
|
|
|
|
<authorgroup>
|
|
<corpauthor>The FreeBSD Documentation Project</corpauthor>
|
|
</authorgroup>
|
|
|
|
<pubdate>April 2000</pubdate>
|
|
|
|
<copyright>
|
|
<year>2000</year>
|
|
<year>2001</year>
|
|
<year>2002</year>
|
|
<year>2003</year>
|
|
<year>2004</year>
|
|
<year>2005</year>
|
|
<year>2006</year>
|
|
<year>2007</year>
|
|
<year>2008</year>
|
|
<year>2009</year>
|
|
<year>2010</year>
|
|
<year>2011</year>
|
|
<year>2012</year>
|
|
<holder role="mailto:doc@FreeBSD.org">The FreeBSD Documentation
|
|
Project</holder>
|
|
</copyright>
|
|
|
|
&trademarks;
|
|
|
|
&legalnotice;
|
|
|
|
<releaseinfo>$FreeBSD$</releaseinfo>
|
|
</bookinfo>
|
|
|
|
<chapter id="why-port">
|
|
<title>Introduction</title>
|
|
|
|
<para>The FreeBSD ports collection is the way almost everyone
|
|
installs applications ("ports") on FreeBSD. Like everything
|
|
else about FreeBSD, it is primarily a volunteer effort.
|
|
It is important to keep this in mind when reading this
|
|
document.</para>
|
|
|
|
<para>In FreeBSD, anyone may submit a new port, or volunteer
|
|
to maintain an existing port if it is unmaintained—you
|
|
do not need any special commit privileges to do so.</para>
|
|
|
|
</chapter>
|
|
|
|
<chapter id="own-port">
|
|
<title>Making a New Port Yourself</title>
|
|
|
|
<para>So, you are interested in making your own port or
|
|
upgrading an existing one? Great!</para>
|
|
|
|
<para>What follows are some guidelines for creating a new port for
|
|
FreeBSD. If you want to upgrade an existing port, you should
|
|
read this and then read <xref linkend="port-upgrading"/>.</para>
|
|
|
|
<para>When this document is not sufficiently detailed, you should
|
|
refer to <filename>/usr/ports/Mk/bsd.port.mk</filename>, which
|
|
all port Makefiles include. Even if you do not hack Makefiles
|
|
daily, it is well commented, and you will still gain much
|
|
knowledge from it. Additionally, you may send specific
|
|
questions to the &a.ports;.</para>
|
|
|
|
<note>
|
|
<para>Only a fraction of the variables
|
|
(<makevar><replaceable>VAR</replaceable></makevar>) that can
|
|
be overridden are mentioned in this document. Most (if not
|
|
all) are documented at the start of
|
|
<filename>/usr/ports/Mk/bsd.port.mk</filename>; the others
|
|
probably ought to be. Note that this file uses a non-standard
|
|
tab setting: <application>Emacs</application> and
|
|
<application>Vim</application> should recognize the setting on
|
|
loading the file. Both &man.vi.1; and &man.ex.1; can be set
|
|
to use the correct value by typing <command>:set
|
|
tabstop=4</command> once the file has been loaded.</para>
|
|
</note>
|
|
|
|
<para>
|
|
Looking for something easy to start with? Take a look at the
|
|
<ulink url="http://wiki.freebsd.org/WantedPorts">list of
|
|
requested ports</ulink> and see if you can work on one (or
|
|
more).</para>
|
|
</chapter>
|
|
|
|
<chapter id="quick-porting">
|
|
<title>Quick Porting</title>
|
|
|
|
<para>This section tells you how to quickly create a new port. In
|
|
many cases, it is not sufficient, so you will have to read
|
|
further on into the document.</para>
|
|
|
|
<para>First, get the original tarball and put it into
|
|
<makevar>DISTDIR</makevar>, which defaults to
|
|
<filename>/usr/ports/distfiles</filename>.</para>
|
|
|
|
<note>
|
|
<para>The following assumes that the software compiled
|
|
out-of-the-box, i.e., there was absolutely no change required
|
|
for the port to work on your FreeBSD box. If you needed to
|
|
change something, you will have to refer to the next section
|
|
too.</para>
|
|
</note>
|
|
|
|
<sect1 id="porting-makefile">
|
|
<title>Writing the <filename>Makefile</filename></title>
|
|
|
|
<para>The minimal <filename>Makefile</filename> would look
|
|
something like this:</para>
|
|
|
|
<programlisting># New ports collection makefile for: oneko
|
|
# Date created: 5 December 1994
|
|
# Whom: asami
|
|
#
|
|
# $FreeBSD$
|
|
#
|
|
|
|
PORTNAME= oneko
|
|
PORTVERSION= 1.1b
|
|
CATEGORIES= games
|
|
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
|
|
|
|
MAINTAINER= asami@FreeBSD.org
|
|
COMMENT= Cat chasing a mouse all over the screen
|
|
|
|
MAN1= oneko.1
|
|
MANCOMPRESSED= yes
|
|
USE_IMAKE= yes
|
|
|
|
.include <bsd.port.mk></programlisting>
|
|
|
|
<para>See if you can figure it out. Do not worry about the
|
|
contents of the <literal>$FreeBSD$</literal>
|
|
line, it will be filled in automatically by SVN when the port
|
|
is imported to our main ports tree. You can find a more
|
|
detailed example in the <link
|
|
linkend="porting-samplem">sample Makefile</link>
|
|
section.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-desc">
|
|
<title>Writing the Description Files</title>
|
|
|
|
<para>There are two description files that are required for
|
|
any port, whether they actually package or not. They are
|
|
<filename>pkg-descr</filename> and
|
|
<filename>pkg-plist</filename>. Their
|
|
<filename>pkg-</filename> prefix distinguishes them from
|
|
other files.</para>
|
|
|
|
<sect2>
|
|
<title><filename>pkg-descr</filename></title>
|
|
|
|
<para>This is a longer description of the port. One to a few
|
|
paragraphs concisely explaining what the port does is
|
|
sufficient.</para>
|
|
|
|
<note>
|
|
<para>This is <emphasis>not</emphasis> a manual or an
|
|
in-depth description on how to use or compile the port!
|
|
<emphasis>Please be careful if you are copying from the
|
|
<filename>README</filename> or manpage</emphasis>; too
|
|
often they are not a concise description of the port or
|
|
are in an awkward format (e.g., manpages have justified
|
|
spacing). If the ported software has an official WWW
|
|
homepage, you should list it here. Prefix
|
|
<emphasis>one</emphasis> of the websites with
|
|
<literal>WWW:</literal> so that automated tools will work
|
|
correctly.</para>
|
|
</note>
|
|
|
|
<para>The following example shows how your
|
|
<filename>pkg-descr</filename> should look:</para>
|
|
|
|
<programlisting>This is a port of oneko, in which a cat chases a poor mouse all over
|
|
the screen.
|
|
:
|
|
(etc.)
|
|
|
|
WWW: http://www.oneko.org/</programlisting>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><filename>pkg-plist</filename></title>
|
|
|
|
<para>This file lists all the files installed by the port. It
|
|
is also called the <quote>packing list</quote> because the
|
|
package is generated by packing the files listed here. The
|
|
pathnames are relative to the installation prefix (usually
|
|
<filename>/usr/local</filename>. If you are using the
|
|
<makevar>MAN<replaceable>n</replaceable></makevar> variables
|
|
(as you should be), do not list any manpages here. If the
|
|
port creates directories during installation, make sure to
|
|
add <literal>@dirrm</literal> lines to remove them when the
|
|
package is deleted.</para>
|
|
|
|
<para>Here is a small example:</para>
|
|
|
|
<programlisting>bin/oneko
|
|
lib/X11/app-defaults/Oneko
|
|
lib/X11/oneko/cat1.xpm
|
|
lib/X11/oneko/cat2.xpm
|
|
lib/X11/oneko/mouse.xpm
|
|
@dirrm lib/X11/oneko</programlisting>
|
|
|
|
<para>Refer to the &man.pkg.create.1; manual page for details
|
|
on the packing list.</para>
|
|
|
|
<note>
|
|
<para>It is recommended that you keep all the filenames in
|
|
this file sorted alphabetically. It will make verifying
|
|
the changes when you upgrade the port much easier.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>Creating a packing list manually can be a very tedious
|
|
task. If the port installs a large numbers of files,
|
|
<link linkend="plist-autoplist">creating the packing list
|
|
automatically</link> might save time.</para>
|
|
</note>
|
|
|
|
<para>There is only one case when
|
|
<filename>pkg-plist</filename> can be omitted from a port.
|
|
If the port installs just a handful of files, and perhaps
|
|
directories, the files and directories may be listed in the
|
|
variables <makevar>PLIST_FILES</makevar> and
|
|
<makevar>PLIST_DIRS</makevar>, respectively, within the
|
|
port's <filename>Makefile</filename>. For instance, we
|
|
could get along without <filename>pkg-plist</filename> in
|
|
the above <filename>oneko</filename> port by adding the
|
|
following lines to the <filename>Makefile</filename>:</para>
|
|
|
|
<programlisting>PLIST_FILES= bin/oneko \
|
|
lib/X11/app-defaults/Oneko \
|
|
lib/X11/oneko/cat1.xpm \
|
|
lib/X11/oneko/cat2.xpm \
|
|
lib/X11/oneko/mouse.xpm
|
|
PLIST_DIRS= lib/X11/oneko</programlisting>
|
|
|
|
<para>Of course, <makevar>PLIST_DIRS</makevar> should be left
|
|
unset if a port installs no directories of its own.</para>
|
|
|
|
<para>The price for this way of listing port's files and
|
|
directories is that you cannot use command sequences
|
|
described in &man.pkg.create.1;. Therefore, it is suitable
|
|
only for simple ports and makes them even simpler. At the
|
|
same time, it has the advantage of reducing the number of
|
|
files in the ports collection. Please consider using this
|
|
technique before you resort to
|
|
<filename>pkg-plist</filename>.</para>
|
|
|
|
<para>Later we will see how <filename>pkg-plist</filename>
|
|
and <makevar>PLIST_FILES</makevar> can be used to fulfill
|
|
<link linkend="plist">more sophisticated
|
|
tasks</link>.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-checksum">
|
|
<title>Creating the Checksum File</title>
|
|
|
|
<para>Just type <command>make makesum</command>. The ports make
|
|
rules will automatically generate the file
|
|
<filename>distinfo</filename>.</para>
|
|
|
|
<para>If a file fetched has its checksum changed regularly and
|
|
you are certain the source is trusted (i.e., it comes from
|
|
manufacturer CDs or documentation generated daily), you should
|
|
specify these files in the <makevar>IGNOREFILES</makevar>
|
|
variable. Then the checksum is not calculated for that file
|
|
when you run <command>make makesum</command>, but set to
|
|
<literal>IGNORE</literal>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-testing">
|
|
<title>Testing the Port</title>
|
|
|
|
<para>You should make sure that the port rules do exactly what
|
|
you want them to do, including packaging up the port. These
|
|
are the important points you need to verify.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><filename>pkg-plist</filename> does not contain
|
|
anything not installed by your port</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>pkg-plist</filename> contains everything
|
|
that is installed by your port</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Your port can be installed multiple times using the
|
|
<maketarget>reinstall</maketarget> target</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Your port <link linkend="plist-cleaning">cleans
|
|
up</link> after itself upon deinstall</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<procedure>
|
|
<title>Recommended Test Ordering</title>
|
|
|
|
<step>
|
|
<para><command>make install</command></para>
|
|
</step>
|
|
|
|
<step>
|
|
<para><command>make package</command></para>
|
|
</step>
|
|
|
|
<step>
|
|
<para><command>make deinstall</command></para>
|
|
</step>
|
|
|
|
<step>
|
|
<para><command>pkg_add
|
|
<replaceable>package-name</replaceable></command></para>
|
|
</step>
|
|
|
|
<step>
|
|
<para><command>make deinstall</command></para>
|
|
</step>
|
|
|
|
<step>
|
|
<para><command>make reinstall</command></para>
|
|
</step>
|
|
|
|
<step>
|
|
<para><command>make package</command></para>
|
|
</step>
|
|
|
|
<step>
|
|
<para><command>make readme</command></para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>Make sure that there are not any warnings issued in any of
|
|
the <maketarget>package</maketarget> and
|
|
<maketarget>deinstall</maketarget> stages. After step 3,
|
|
check to see if all the new directories are correctly deleted.
|
|
Also, try using the software after step 4, to ensure that it
|
|
works correctly when installed from a package.</para>
|
|
|
|
<para>The most thorough way to automate these steps is via
|
|
installing the <application>ports tinderbox</application>.
|
|
This maintains <literal>jails</literal> in which you can
|
|
test all of the above steps without changing the state of
|
|
your running system. Please see
|
|
<filename>ports/ports-mgmt/tinderbox</filename> for more
|
|
information.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-portlint">
|
|
<title>Checking Your Port with
|
|
<command>portlint</command></title>
|
|
|
|
<para>Please use <command>portlint</command> to see if your port
|
|
conforms to our guidelines. The <filename
|
|
role="package">ports-mgmt/portlint</filename> program is
|
|
part of the ports collection. In particular, you may want to
|
|
check if the <link linkend="porting-samplem">Makefile</link>
|
|
is in the right shape and the <link
|
|
linkend="porting-pkgname">package</link> is named
|
|
appropriately.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-submitting">
|
|
<title>Submitting the New Port</title>
|
|
|
|
<para>Before you submit the new port, make sure you have read
|
|
the <link
|
|
linkend="porting-dads">DOs and DON'Ts</link> section.</para>
|
|
|
|
<para>Now that you are happy with your port, the only thing
|
|
remaining is to put it in the main &os; ports tree and make
|
|
everybody else happy about it too. We do not need your
|
|
<filename>work</filename> directory or the
|
|
<filename>pkgname.tgz</filename> package, so delete them now.
|
|
Next, assuming your port is called oneko,
|
|
<command>cd</command> to the directory above where the
|
|
<literal>oneko</literal> directory is located, and then type
|
|
the following: <command>shar `find oneko` >
|
|
oneko.shar</command></para>
|
|
|
|
<para>Include your <literal>oneko.shar</literal> file in a bug
|
|
report and send it with the &man.send-pr.1; program (see
|
|
<ulink
|
|
url="&url.articles.contributing;/contrib-how.html#CONTRIB-GENERAL">Bug
|
|
Reports and General Commentary</ulink> for more information
|
|
about &man.send-pr.1;). Be sure to classify the bug report
|
|
as category <literal>ports</literal> and class
|
|
<literal>change-request</literal> (Do not mark the report
|
|
<literal>confidential</literal>!). Also add a short
|
|
description of the program you ported to the
|
|
<quote>Description</quote> field of the PR (e.g., perhaps a
|
|
short version of the <makevar>COMMENT</makevar>), and add
|
|
the shar file to the <quote>Fix</quote> field.</para>
|
|
|
|
<note>
|
|
<para>You can make our work a lot easier, if you use a good
|
|
description in the synopsis of the problem report. We
|
|
prefer something like <quote>New port:
|
|
<category>/<portname> <short description of
|
|
the port></quote> for new ports. If you stick to this
|
|
scheme, the chance that someone will take a look at your PR
|
|
soon is much better.</para>
|
|
</note>
|
|
|
|
<para>One more time, <emphasis>do not include the original
|
|
source distfile, the <filename>work</filename> directory, or
|
|
the package you built with <command>make
|
|
package</command></emphasis>; and, do use &man.shar.1; for
|
|
new ports, not &man.diff.1;.</para>
|
|
|
|
<para>After you have submitted your port, please be patient.
|
|
Sometimes it can take a few months before a port is included
|
|
in &os;, although it might only take a few days. You can
|
|
view the list of <ulink
|
|
url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?category=ports">ports
|
|
PRs waiting to be committed to &os;</ulink>.</para>
|
|
|
|
<para>Once we have looked at your port, we will get back to you
|
|
if necessary, and put it in the tree. Your name will also
|
|
appear in the list of <ulink
|
|
url="&url.articles.contributors;/contrib-additional.html">Additional
|
|
FreeBSD Contributors</ulink> and other files. Isn't that
|
|
great?!? <!-- smiley -->:-)</para>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="slow">
|
|
<title>Slow Porting</title>
|
|
|
|
<para>Ok, so it was not that simple, and the port required some
|
|
modifications to get it to work. In this section, we will
|
|
explain, step by step, how to modify it to get it to work with
|
|
the ports paradigm.</para>
|
|
|
|
<sect1 id="slow-work">
|
|
<title>How Things Work</title>
|
|
|
|
<para>First, this is the sequence of events which occurs when
|
|
the user first types <command>make</command> in your port's
|
|
directory. You may find that having
|
|
<filename>bsd.port.mk</filename> in another window while you
|
|
read this really helps to understand it.</para>
|
|
|
|
<para>But do not worry if you do not really understand what
|
|
<filename>bsd.port.mk</filename> is doing, not many people
|
|
do... <!-- smiley --><emphasis>:-)</emphasis></para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>The <maketarget>fetch</maketarget> target is run. The
|
|
<maketarget>fetch</maketarget> target is responsible for
|
|
making sure that the tarball exists locally in
|
|
<makevar>DISTDIR</makevar>. If
|
|
<maketarget>fetch</maketarget> cannot find the required
|
|
files in <makevar>DISTDIR</makevar> it will look up the
|
|
URL <makevar>MASTER_SITES</makevar>, which is set in the
|
|
Makefile, as well as our main FTP site at <ulink
|
|
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/"></ulink>,
|
|
where we put sanctioned distfiles as backup. It will then
|
|
attempt to fetch the named distribution file with
|
|
<makevar>FETCH</makevar>, assuming that the requesting
|
|
site has direct access to the Internet. If that succeeds,
|
|
it will save the file in <makevar>DISTDIR</makevar> for
|
|
future use and proceed.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The <maketarget>extract</maketarget> target is run.
|
|
It looks for your port's distribution file (typically a
|
|
<command>gzip</command>ped tarball) in
|
|
<makevar>DISTDIR</makevar> and unpacks it into a temporary
|
|
subdirectory specified by <makevar>WRKDIR</makevar>
|
|
(defaults to <filename>work</filename>).</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The <maketarget>patch</maketarget> target is run.
|
|
First, any patches defined in
|
|
<makevar>PATCHFILES</makevar> are applied. Second, if any
|
|
patch files named
|
|
<filename>patch-<replaceable>*</replaceable></filename>
|
|
are found in <makevar>PATCHDIR</makevar> (defaults to the
|
|
<filename>files</filename> subdirectory), they are applied
|
|
at this time in alphabetical order.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The <maketarget>configure</maketarget> target is run.
|
|
This can do any one of many different things.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>If it exists,
|
|
<filename>scripts/configure</filename> is run.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If <makevar>HAS_CONFIGURE</makevar> or
|
|
<makevar>GNU_CONFIGURE</makevar> is set,
|
|
<filename><makevar>WRKSRC</makevar>/configure</filename>
|
|
is run.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If <makevar>USE_IMAKE</makevar> is set,
|
|
<makevar>XMKMF</makevar> (default: <command>xmkmf
|
|
-a</command>) is run.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The <maketarget>build</maketarget> target is run.
|
|
This is responsible for descending into the port's private
|
|
working directory (<makevar>WRKSRC</makevar>) and building
|
|
it. If <makevar>USE_GMAKE</makevar> is set, GNU
|
|
<command>make</command> will be used, otherwise the system
|
|
<command>make</command> will be used.</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>The above are the default actions. In addition, you can
|
|
define targets
|
|
<maketarget>pre-<replaceable>something</replaceable></maketarget>
|
|
or
|
|
<maketarget>post-<replaceable>something</replaceable></maketarget>,
|
|
or put scripts with those names, in the
|
|
<filename>scripts</filename> subdirectory, and they will be
|
|
run before or after the default actions are done.</para>
|
|
|
|
<para>For example, if you have a
|
|
<maketarget>post-extract</maketarget> target defined in your
|
|
<filename>Makefile</filename>, and a file
|
|
<filename>pre-build</filename> in the
|
|
<filename>scripts</filename> subdirectory, the
|
|
<maketarget>post-extract</maketarget> target will be called
|
|
after the regular extraction actions, and the
|
|
<filename>pre-build</filename> script will be executed before
|
|
the default build rules are done. It is recommended that you
|
|
use <filename>Makefile</filename> targets if the actions are
|
|
simple enough, because it will be easier for someone to figure
|
|
out what kind of non-default action the port requires.</para>
|
|
|
|
<para>The default actions are done by the
|
|
<filename>bsd.port.mk</filename> targets
|
|
<maketarget>do-<replaceable>something</replaceable></maketarget>.
|
|
For example, the commands to extract a port are in the target
|
|
<maketarget>do-extract</maketarget>. If you are not happy
|
|
with the default target, you can fix it by redefining the
|
|
<maketarget>do-<replaceable>something</replaceable></maketarget>
|
|
target in your <filename>Makefile</filename>.</para>
|
|
|
|
<note>
|
|
<para>The <quote>main</quote> targets (e.g.,
|
|
<maketarget>extract</maketarget>,
|
|
<maketarget>configure</maketarget>, etc.) do nothing more
|
|
than make sure all the stages up to that one are completed
|
|
and call the real targets or scripts, and they are not
|
|
intended to be changed. If you want to fix the extraction,
|
|
fix <maketarget>do-extract</maketarget>, but never ever
|
|
change the way <maketarget>extract</maketarget>
|
|
operates! Additionally, the target
|
|
<maketarget>post-deinstall</maketarget> is invalid and
|
|
is not run by the ports infrastructure.</para>
|
|
</note>
|
|
|
|
<para>Now that you understand what goes on when the user types
|
|
<command>make</command>, let us go through the recommended
|
|
steps to create the perfect port.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="slow-sources">
|
|
<title>Getting the Original Sources</title>
|
|
|
|
<para>Get the original sources (normally) as a compressed
|
|
tarball
|
|
(<filename><replaceable>foo</replaceable>.tar.gz</filename> or
|
|
<filename><replaceable>foo</replaceable>.tar.bz2</filename>)
|
|
and copy it into <makevar>DISTDIR</makevar>. Always use
|
|
<emphasis>mainstream</emphasis> sources when and where you
|
|
can.</para>
|
|
|
|
<para>You will need to set the variable
|
|
<makevar>MASTER_SITES</makevar> to reflect where the original
|
|
tarball resides. You will find convenient shorthand
|
|
definitions for most mainstream sites in
|
|
<filename>bsd.sites.mk</filename>. Please use these
|
|
sites—and the associated definitions—if at all
|
|
possible, to help avoid the problem of having the same
|
|
information repeated over again many times in the source base.
|
|
As these sites tend to change over time, this becomes a
|
|
maintenance nightmare for everyone involved.</para>
|
|
|
|
<para>If you cannot find a FTP/HTTP site that is well-connected
|
|
to the net, or can only find sites that have irritatingly
|
|
non-standard formats, you might want to put a copy on a
|
|
reliable FTP or HTTP server that you control (e.g., your home
|
|
page).</para>
|
|
|
|
<para>If you cannot find somewhere convenient and reliable to
|
|
put the distfile we can <quote>house</quote> it ourselves on
|
|
<hostid>ftp.FreeBSD.org</hostid>; however, this is the
|
|
least-preferred solution. The distfile must be placed into
|
|
<filename>~/public_distfiles/</filename> of someone's
|
|
<hostid>freefall</hostid> account. Ask the person who commits
|
|
your port to do this. This person will also set
|
|
<makevar>MASTER_SITES</makevar> to
|
|
<makevar>MASTER_SITE_LOCAL</makevar> and
|
|
<makevar>MASTER_SITE_SUBDIR</makevar> to their
|
|
<hostid>freefall</hostid> username.</para>
|
|
|
|
<para>If your port's distfile changes all the time without any
|
|
kind of version update by the author, consider putting the
|
|
distfile on your home page and listing it as the first
|
|
<makevar>MASTER_SITES</makevar>. If you can, try to talk the
|
|
port author out of doing this; it really does help to
|
|
establish some kind of source code control. Hosting your own
|
|
version will prevent users from getting <errorname>checksum
|
|
mismatch</errorname> errors, and also reduce the workload of
|
|
maintainers of our FTP site. Also, if there is only one
|
|
master site for the port, it is recommended that you house a
|
|
backup at your site and list it as the second
|
|
<makevar>MASTER_SITES</makevar>.</para>
|
|
|
|
<para>If your port requires some additional `patches' that are
|
|
available on the Internet, fetch them too and put them in
|
|
<makevar>DISTDIR</makevar>. Do not worry if they come from a
|
|
site other than where you got the main source tarball, we have
|
|
a way to handle these situations (see the description of <link
|
|
linkend="porting-patchfiles">PATCHFILES</link>
|
|
below).</para>
|
|
</sect1>
|
|
|
|
<sect1 id="slow-modifying">
|
|
<title>Modifying the Port</title>
|
|
|
|
<para>Unpack a copy of the tarball in a private directory and
|
|
make whatever changes are necessary to get the port to compile
|
|
properly under the current version of &os;. Keep
|
|
<emphasis>careful track</emphasis> of everything you do, as
|
|
you will be automating the process shortly. Everything,
|
|
including the deletion, addition, or modification of files
|
|
should be doable using an automated script or patch file when
|
|
your port is finished.</para>
|
|
|
|
<para>If your port requires significant user
|
|
interaction/customization to compile or install, you should
|
|
take a look at one of Larry Wall's classic
|
|
<application>Configure</application> scripts and perhaps do
|
|
something similar yourself. The goal of the new ports
|
|
collection is to make each port as
|
|
<quote>plug-and-play</quote> as possible for the end-user
|
|
while using a minimum of disk space.</para>
|
|
|
|
<note>
|
|
<para>Unless explicitly stated, patch files, scripts, and
|
|
other files you have created and contributed to the &os;
|
|
ports collection are assumed to be covered by the standard
|
|
BSD copyright conditions.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="slow-patch">
|
|
<title>Patching</title>
|
|
|
|
<para>In the preparation of the port, files that have been added
|
|
or changed can be picked up with a &man.diff.1; for later
|
|
feeding to &man.patch.1;. Each patch you wish to apply should
|
|
be saved into a file named
|
|
<filename>patch-<replaceable>*</replaceable></filename> where
|
|
<replaceable>*</replaceable> indicates the pathname of the
|
|
file that is patched, such as
|
|
<filename>patch-Imakefile</filename> or
|
|
<filename>patch-src-config.h</filename>. These files should
|
|
be stored in <makevar>PATCHDIR</makevar> (usually
|
|
<filename>files/</filename>, from where they will be
|
|
automatically applied. All patches must be relative to
|
|
<makevar>WRKSRC</makevar> (generally the directory your port's
|
|
tarball unpacks itself into, that being where the build is
|
|
done). To make fixes and upgrades easier, you should avoid
|
|
having more than one patch fix the same file (e.g.,
|
|
<filename>patch-file</filename> and
|
|
<filename>patch-file2</filename> both changing
|
|
<filename><makevar>WRKSRC</makevar>/foobar.c</filename>).
|
|
Note that if the path of a patched file contains an underscore
|
|
(<literal>_</literal>) character, the patch needs to have two
|
|
underscores instead in its name. For example, to patch a file
|
|
named <filename>src/freeglut_joystick.c</filename>, the
|
|
corresponding patch should be named
|
|
<filename>patch-src-freeglut__joystick.c</filename>.</para>
|
|
|
|
<para>Please only use characters
|
|
<literal>[-+._a-zA-Z0-9]</literal> for naming your patches.
|
|
Do not use any other characters besides them. Do not name
|
|
your patches like <filename>patch-aa</filename> or
|
|
<filename>patch-ab</filename> etc, always mention the path and
|
|
file name in patch names.</para>
|
|
|
|
<para>Do not put RCS strings in patches. SVN will mangle them
|
|
when we put the files into the ports tree, and when we check
|
|
them out again, they will come out different and the patch
|
|
will fail. RCS strings are surrounded by dollar
|
|
(<literal>$</literal>) signs, and typically start with
|
|
<literal>$Id</literal> or
|
|
<literal>$RCS</literal>.</para>
|
|
|
|
<para>Using the recurse (<option>-r</option>) option to
|
|
&man.diff.1; to generate patches is fine, but please take a
|
|
look at the resulting patches to make sure you do not have any
|
|
unnecessary junk in there. In particular, diffs between two
|
|
backup files, <filename>Makefile</filename>s when the port
|
|
uses <command>Imake</command> or GNU
|
|
<command>configure</command>, etc., are unnecessary and should
|
|
be deleted. If you had to edit
|
|
<filename>configure.in</filename> and run
|
|
<command>autoconf</command> to regenerate
|
|
<command>configure</command>, do not take the diffs of
|
|
<command>configure</command> (it often grows to a few thousand
|
|
lines!); define <literal>USE_AUTOTOOLS=autoconf:261</literal>
|
|
and take the diffs of
|
|
<filename>configure.in</filename>.</para>
|
|
|
|
<para>Also, try to minimize the amount of non-functional
|
|
whitespace changes in your patches. It is common in the Open
|
|
Source world for projects to share large amounts of a code
|
|
base, but obey different style and indenting rules. If you
|
|
take a working piece of functionality from one project to fix
|
|
similar areas in another, please be careful: the resulting
|
|
line patch may be full of non-functional changes. It not only
|
|
increases the size of the SVN repository but makes it hard to
|
|
find out what exactly caused the problem and what you changed
|
|
at all.</para>
|
|
|
|
<para>If you had to delete a file, then you can do it in the
|
|
<maketarget>post-extract</maketarget> target rather than as
|
|
part of the patch.</para>
|
|
|
|
<para>Simple replacements can be performed directly from the
|
|
port <filename>Makefile</filename> using the in-place mode of
|
|
&man.sed.1;. This is very useful when you need to patch in a
|
|
variable value. Example:</para>
|
|
|
|
<programlisting>post-patch:
|
|
@${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README
|
|
@${REINPLACE_CMD} -e 's|-pthread|${PTHREAD_LIBS}|' ${WRKSRC}/configure</programlisting>
|
|
|
|
<para>Quite often, there is a situation when the software being
|
|
ported, especially if it is primarily developed on &windows;,
|
|
uses the CR/LF convention for most of its source files. This
|
|
may cause problems with further patching, compiler warnings,
|
|
scripts execution (<command>/bin/sh^M</command> not found),
|
|
etc. To quickly convert all files from CR/LF to just LF, add
|
|
<literal>USE_DOS2UNIX=yes</literal> to the port
|
|
<filename>Makefile</filename>. A list of files to convert can
|
|
be specified:</para>
|
|
|
|
<programlisting>USE_DOS2UNIX= util.c util.h</programlisting>
|
|
|
|
<para>If you want to convert a group of files across
|
|
subdirectories, <makevar>DOS2UNIX_REGEX</makevar> can be used.
|
|
Its argument is a <command>find</command> compatible regular
|
|
expression. More on the format is in &man.re.format.7;. This
|
|
option is useful for converting all files of a given
|
|
extension, for example all source code files leaving binary
|
|
files intact:</para>
|
|
|
|
<programlisting>USE_DOS2UNIX= yes
|
|
DOS2UNIX_REGEX= .*\.(c|cpp|h)</programlisting>
|
|
|
|
<para>If you want to create a patch file based off of an
|
|
existing file, you can copy it with an
|
|
<filename>.orig</filename> extension, and then modify the
|
|
original one. The <maketarget>makepatch</maketarget> target
|
|
will write out an appropriate patch file to the <filename
|
|
class="directory">files</filename> directory of the
|
|
port.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="slow-configure">
|
|
<title>Configuring</title>
|
|
|
|
<para>Include any additional customization commands in your
|
|
<filename>configure</filename> script and save it in the
|
|
<filename>scripts</filename> subdirectory. As mentioned
|
|
above, you can also do this with <filename>Makefile</filename>
|
|
targets and/or scripts with the name
|
|
<filename>pre-configure</filename> or
|
|
<filename>post-configure</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="slow-user-input">
|
|
<title>Handling User Input</title>
|
|
|
|
<para>If your port requires user input to build, configure, or
|
|
install, you must set <makevar>IS_INTERACTIVE</makevar> in
|
|
your <filename>Makefile</filename>. This will allow
|
|
<quote>overnight builds</quote> to skip your port if the user
|
|
sets the variable <envar>BATCH</envar> in his environment (and
|
|
if the user sets the variable <envar>INTERACTIVE</envar>, then
|
|
<emphasis>only</emphasis> those ports requiring interaction
|
|
are built). This will save a lot of wasted time on the set of
|
|
machines that continually build ports (see below).</para>
|
|
|
|
<para>It is also recommended that if there are reasonable
|
|
default answers to the questions, you check the
|
|
<makevar>PACKAGE_BUILDING</makevar> variable and turn off the
|
|
interactive script when it is set. This will allow us to
|
|
build the packages for CDROMs and FTP.</para>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="makefile">
|
|
<title>Configuring the Makefile</title>
|
|
|
|
<para>Configuring the <filename>Makefile</filename> is pretty
|
|
simple, and again we suggest that you look at existing examples
|
|
before starting. Also, there is a <link
|
|
linkend="porting-samplem">sample Makefile</link> in this
|
|
handbook, so take a look and please follow the ordering of
|
|
variables and sections in that template to make your port easier
|
|
for others to read.</para>
|
|
|
|
<para>Now, consider the following problems in sequence as you
|
|
design your new <filename>Makefile</filename>:</para>
|
|
|
|
<sect1 id="makefile-source">
|
|
<title>The Original Source</title>
|
|
|
|
<para>Does it live in <makevar>DISTDIR</makevar> as a standard
|
|
<command>gzip</command>ped tarball named something like
|
|
<filename>foozolix-1.2.tar.gz</filename>? If so, you can go on
|
|
to the next step. If not, you should look at overriding any
|
|
of the <makevar>DISTVERSION</makevar>,
|
|
<makevar>DISTNAME</makevar>, <makevar>EXTRACT_CMD</makevar>,
|
|
<makevar>EXTRACT_BEFORE_ARGS</makevar>,
|
|
<makevar>EXTRACT_AFTER_ARGS</makevar>,
|
|
<makevar>EXTRACT_SUFX</makevar>, or
|
|
<makevar>DISTFILES</makevar> variables, depending on how alien
|
|
a format your port's distribution file is.</para>
|
|
|
|
<para>In the worst case, you can simply create your own
|
|
<maketarget>do-extract</maketarget> target to override the
|
|
default, though this should be rarely, if ever,
|
|
necessary.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-naming">
|
|
<title>Naming</title>
|
|
|
|
<para>The first part of the port's <filename>Makefile</filename>
|
|
names the port, describes its version number, and lists it
|
|
in the correct category.</para>
|
|
|
|
<sect2>
|
|
<title><makevar>PORTNAME</makevar> and
|
|
<makevar>PORTVERSION</makevar></title>
|
|
|
|
<para>You should set <makevar>PORTNAME</makevar> to the
|
|
base name of your port, and <makevar>PORTVERSION</makevar>
|
|
to the version number of the port.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="makefile-naming-revepoch">
|
|
<title><makevar>PORTREVISION</makevar> and
|
|
<makevar>PORTEPOCH</makevar></title>
|
|
|
|
<sect3>
|
|
<title><makevar>PORTREVISION</makevar></title>
|
|
|
|
<para>The <makevar>PORTREVISION</makevar> variable is a
|
|
monotonically increasing value which is reset to 0 with
|
|
every increase of <makevar>PORTVERSION</makevar> (i.e.
|
|
every time a new official vendor release is made), and
|
|
appended to the package name if non-zero. Changes to
|
|
<makevar>PORTREVISION</makevar> are used by automated
|
|
tools (e.g., &man.pkg.version.1;) to highlight the fact
|
|
that a new package is available.</para>
|
|
|
|
<para><makevar>PORTREVISION</makevar> should be increased
|
|
each time a change is made to the port which significantly
|
|
affects the content or structure of the derived
|
|
package.</para>
|
|
|
|
<para>Examples of when <makevar>PORTREVISION</makevar>
|
|
should be bumped:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Addition of patches to correct security
|
|
vulnerabilities, bugs, or to add new functionality to
|
|
the port.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Changes to the port <filename>Makefile</filename>
|
|
to enable or disable compile-time options in the
|
|
package.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Changes in the packing list or the install-time
|
|
behavior of the package (e.g., change to a script
|
|
which generates initial data for the package, like ssh
|
|
host keys).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Version bump of a port's shared library dependency
|
|
(in this case, someone trying to install the old
|
|
package after installing a newer version of the
|
|
dependency will fail since it will look for the old
|
|
libfoo.x instead of libfoo.(x+1)).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Silent changes to the port distfile which have
|
|
significant functional differences, i.e., changes to
|
|
the distfile requiring a correction to
|
|
<filename>distinfo</filename> with no corresponding
|
|
change to <makevar>PORTVERSION</makevar>, where a
|
|
<command>diff -ru</command> of the old and new
|
|
versions shows non-trivial changes to the code.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Examples of changes which do not require a
|
|
<makevar>PORTREVISION</makevar> bump:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Style changes to the port skeleton with no
|
|
functional change to what appears in the resulting
|
|
package.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Changes to <makevar>MASTER_SITES</makevar> or
|
|
other functional changes to the port which do not
|
|
affect the resulting package.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Trivial patches to the distfile such as correction
|
|
of typos, which are not important enough that users of
|
|
the package should go to the trouble of
|
|
upgrading.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Build fixes which cause a package to become
|
|
compilable where it was previously failing (as long as
|
|
the changes do not introduce any functional change on
|
|
any other platforms on which the port did previously
|
|
build). Since <makevar>PORTREVISION</makevar>
|
|
reflects the content of the package, if the package
|
|
was not previously buildable then there is no need to
|
|
increase <makevar>PORTREVISION</makevar> to mark a
|
|
change.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>A rule of thumb is to ask yourself whether a change
|
|
committed to a port is something which everyone would
|
|
benefit from having (either because of an enhancement,
|
|
fix, or by virtue that the new package will actually work
|
|
at all), and weigh that against that fact that it will
|
|
cause everyone who regularly updates their ports tree to
|
|
be compelled to update. If yes, the
|
|
<makevar>PORTREVISION</makevar> should be bumped.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title><makevar>PORTEPOCH</makevar></title>
|
|
|
|
<para>From time to time a software vendor or FreeBSD porter
|
|
will do something silly and release a version of their
|
|
software which is actually numerically less than the
|
|
previous version. An example of this is a port which goes
|
|
from foo-20000801 to foo-1.0 (the former will be
|
|
incorrectly treated as a newer version since 20000801 is a
|
|
numerically greater value than 1).</para>
|
|
|
|
<para>In situations such as this, the
|
|
<makevar>PORTEPOCH</makevar> version should be increased.
|
|
If <makevar>PORTEPOCH</makevar> is nonzero it is appended
|
|
to the package name as described in section 0 above.
|
|
<makevar>PORTEPOCH</makevar> must never be decreased or
|
|
reset to zero, because that would cause comparison to a
|
|
package from an earlier epoch to fail (i.e., the package
|
|
would not be detected as out of date): the new version
|
|
number (e.g., <literal>1.0,1</literal> in the above
|
|
example) is still numerically less than the previous
|
|
version (20000801), but the <literal>,1</literal> suffix
|
|
is treated specially by automated tools and found to be
|
|
greater than the implied suffix <literal>,0</literal> on
|
|
the earlier package.</para>
|
|
|
|
<para>Dropping or resetting <makevar>PORTEPOCH</makevar>
|
|
incorrectly leads to no end of grief; if you do not
|
|
understand the above discussion, please keep after it
|
|
until you do, or ask questions on the mailing
|
|
lists.</para>
|
|
|
|
<para>It is expected that <makevar>PORTEPOCH</makevar> will
|
|
not be used for the majority of ports, and that sensible
|
|
use of <makevar>PORTVERSION</makevar> can often preempt it
|
|
becoming necessary if a future release of the software
|
|
should change the version structure. However, care is
|
|
needed by FreeBSD porters when a vendor release is made
|
|
without an official version number — such as a code
|
|
<quote>snapshot</quote> release. The temptation is to
|
|
label the release with the release date, which will cause
|
|
problems as in the example above when a new
|
|
<quote>official</quote> release is made.</para>
|
|
|
|
<para>For example, if a snapshot release is made on the date
|
|
20000917, and the previous version of the software was
|
|
version 1.2, the snapshot release should be given a
|
|
<makevar>PORTVERSION</makevar> of 1.2.20000917 or similar,
|
|
not 20000917, so that the succeeding release, say 1.3, is
|
|
still a numerically greater value.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Example of <makevar>PORTREVISION</makevar> and
|
|
<makevar>PORTEPOCH</makevar> Usage</title>
|
|
|
|
<para>The <literal>gtkmumble</literal> port, version
|
|
<literal>0.10</literal>, is committed to the ports
|
|
collection:</para>
|
|
|
|
<programlisting>PORTNAME= gtkmumble
|
|
PORTVERSION= 0.10</programlisting>
|
|
|
|
<para><makevar>PKGNAME</makevar> becomes
|
|
<literal>gtkmumble-0.10</literal>.</para>
|
|
|
|
<para>A security hole is discovered which requires a local
|
|
FreeBSD patch. <makevar>PORTREVISION</makevar> is bumped
|
|
accordingly.</para>
|
|
|
|
<programlisting>PORTNAME= gtkmumble
|
|
PORTVERSION= 0.10
|
|
PORTREVISION= 1</programlisting>
|
|
|
|
<para><makevar>PKGNAME</makevar> becomes
|
|
<literal>gtkmumble-0.10_1</literal></para>
|
|
|
|
<para>A new version is released by the vendor, numbered
|
|
<literal>0.2</literal> (it turns out the author actually
|
|
intended <literal>0.10</literal> to actually mean
|
|
<literal>0.1.0</literal>, not <quote>what comes after
|
|
0.9</quote> - oops, too late now). Since the new minor
|
|
version <literal>2</literal> is numerically less than the
|
|
previous version <literal>10</literal>, the
|
|
<makevar>PORTEPOCH</makevar> must be bumped to manually
|
|
force the new package to be detected as
|
|
<quote>newer</quote>. Since it is a new vendor release of
|
|
the code, <makevar>PORTREVISION</makevar> is reset to 0
|
|
(or removed from the
|
|
<filename>Makefile</filename>).</para>
|
|
|
|
<programlisting>PORTNAME= gtkmumble
|
|
PORTVERSION= 0.2
|
|
PORTEPOCH= 1</programlisting>
|
|
|
|
<para><makevar>PKGNAME</makevar> becomes
|
|
<literal>gtkmumble-0.2,1</literal></para>
|
|
|
|
<para>The next release is 0.3. Since
|
|
<makevar>PORTEPOCH</makevar> never decreases, the version
|
|
variables are now:</para>
|
|
|
|
<programlisting>PORTNAME= gtkmumble
|
|
PORTVERSION= 0.3
|
|
PORTEPOCH= 1</programlisting>
|
|
|
|
<para><makevar>PKGNAME</makevar> becomes
|
|
<literal>gtkmumble-0.3,1</literal></para>
|
|
|
|
<note>
|
|
<para>If <makevar>PORTEPOCH</makevar> were reset to
|
|
<literal>0</literal> with this upgrade, someone who had
|
|
installed the <literal>gtkmumble-0.10_1</literal>
|
|
package would not detect the
|
|
<literal>gtkmumble-0.3</literal> package as newer, since
|
|
<literal>3</literal> is still numerically less than
|
|
<literal>10</literal>. Remember, this is the whole
|
|
point of <makevar>PORTEPOCH</makevar> in the first
|
|
place.</para>
|
|
</note>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>PKGNAMEPREFIX</makevar> and
|
|
<makevar>PKGNAMESUFFIX</makevar></title>
|
|
|
|
<para>Two optional variables, <makevar>PKGNAMEPREFIX</makevar>
|
|
and <makevar>PKGNAMESUFFIX</makevar>, are combined with
|
|
<makevar>PORTNAME</makevar> and
|
|
<makevar>PORTVERSION</makevar> to form
|
|
<makevar>PKGNAME</makevar> as
|
|
<literal>${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}</literal>.
|
|
Make sure this conforms to our <link
|
|
linkend="porting-pkgname">guidelines for a good package
|
|
name</link>. In particular, you are
|
|
<emphasis>not</emphasis> allowed to use a hyphen
|
|
(<literal>-</literal>) in <makevar>PORTVERSION</makevar>.
|
|
Also, if the package name has the
|
|
<replaceable>language-</replaceable> or the
|
|
<replaceable>-compiled.specifics</replaceable> part (see
|
|
below), use <makevar>PKGNAMEPREFIX</makevar> and
|
|
<makevar>PKGNAMESUFFIX</makevar>, respectively. Do not make
|
|
them part of <makevar>PORTNAME</makevar>.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>LATEST_LINK</makevar></title>
|
|
|
|
<para><makevar>LATEST_LINK</makevar> is used during package
|
|
building to determine a shortened name to create links that
|
|
can be used by <command>pkg_add -r</command>. This makes it
|
|
possible to, for example, install the latest perl version by
|
|
running <command>pkg_add -r perl</command> without knowing
|
|
the exact version number. This name needs to be unique and
|
|
obvious to users.</para>
|
|
|
|
<para>In some cases, several versions of a program may be
|
|
present in the ports collection at the same time. Both the
|
|
index build and the package build system need to be able to
|
|
see them as different, independent ports, although they may
|
|
all have the same <makevar>PORTNAME</makevar>,
|
|
<makevar>PKGNAMEPREFIX</makevar>, and even
|
|
<makevar>PKGNAMESUFFIX</makevar>. In those cases, the
|
|
optional <makevar>LATEST_LINK</makevar> variable should be
|
|
set to a different value for all ports except the
|
|
<quote>main</quote> one — see the
|
|
<filename>lang/gcc46</filename> and
|
|
<filename>lang/gcc</filename> ports, and the
|
|
<filename>www/apache*</filename> family for examples of its
|
|
use. By setting <makevar>NO_LATEST_LINK</makevar>, no link
|
|
will be generated, which may be an option for all but the
|
|
<quote>main</quote> version. Note that how to choose a
|
|
<quote>main</quote> version — <quote>most
|
|
popular</quote>, <quote>best supported</quote>,
|
|
<quote>least patched</quote>, and so on — is outside
|
|
the scope of this handbook's recommendations; we only tell
|
|
you how to specify the other ports' versions after you have
|
|
picked a <quote>main</quote> one.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="porting-pkgname">
|
|
<title>Package Naming Conventions</title>
|
|
|
|
<para>The following are the conventions you should follow in
|
|
naming your packages. This is to have our package directory
|
|
easy to scan, as there are already thousands of packages and
|
|
users are going to turn away if they hurt their eyes!</para>
|
|
|
|
<para>The package name should look like
|
|
<filename><replaceable><optional>language<optional>_region</optional></optional>-name<optional><optional>-</optional>compiled.specifics</optional>-version.numbers</replaceable></filename>.</para>
|
|
|
|
<para>The package name is defined as
|
|
<literal>${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}</literal>.
|
|
Make sure to set the variables to conform to that
|
|
format.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>FreeBSD strives to support the native language of
|
|
its users. The <replaceable>language-</replaceable>
|
|
part should be a two letter abbreviation of the natural
|
|
language defined by ISO-639 if the port is specific to a
|
|
certain language. Examples are <literal>ja</literal>
|
|
for Japanese, <literal>ru</literal> for Russian,
|
|
<literal>vi</literal> for Vietnamese,
|
|
<literal>zh</literal> for Chinese, <literal>ko</literal>
|
|
for Korean and <literal>de</literal> for German.</para>
|
|
|
|
<para>If the port is specific to a certain region within
|
|
the language area, add the two letter country code as
|
|
well. Examples are <literal>en_US</literal> for US
|
|
English and <literal>fr_CH</literal> for Swiss
|
|
French.</para>
|
|
|
|
<para>The <replaceable>language-</replaceable> part should
|
|
be set in the <makevar>PKGNAMEPREFIX</makevar>
|
|
variable.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The first letter of the <filename>name</filename>
|
|
part should be lowercase. (The rest of the name may
|
|
contain capital letters, so use your own discretion when
|
|
you are converting a software name that has some capital
|
|
letters in it.) There is a tradition of naming
|
|
<literal>Perl 5</literal> modules by prepending
|
|
<literal>p5-</literal> and converting the double-colon
|
|
separator to a hyphen; for example, the
|
|
<literal>Data::Dumper</literal> module becomes
|
|
<literal>p5-Data-Dumper</literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Make sure that the port's name and version are
|
|
clearly separated and placed into the
|
|
<makevar>PORTNAME</makevar> and
|
|
<makevar>PORTVERSION</makevar> variables. The only
|
|
reason for <makevar>PORTNAME</makevar> to contain a
|
|
version part is if the upstream distribution is really
|
|
named that way, as in the
|
|
<filename>textproc/libxml2</filename> or
|
|
<filename>japanese/kinput2-freewnn</filename> ports.
|
|
Otherwise, the <makevar>PORTNAME</makevar> should not
|
|
contain any version-specific information. It is quite
|
|
normal for several ports to have the same
|
|
<makevar>PORTNAME</makevar>, as the
|
|
<filename>www/apache*</filename> ports do; in that case,
|
|
different versions (and different index entries) are
|
|
distinguished by the <makevar>PKGNAMEPREFIX</makevar>,
|
|
<makevar>PKGNAMESUFFIX</makevar>, and
|
|
<makevar>LATEST_LINK</makevar> values.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the port can be built with different <link
|
|
linkend="makefile-masterdir">hardcoded defaults</link>
|
|
(usually part of the directory name in a family of
|
|
ports), the
|
|
<replaceable>-compiled.specifics</replaceable> part
|
|
should state the compiled-in defaults (the hyphen is
|
|
optional). Examples are paper size and font
|
|
units.</para>
|
|
|
|
<para>The <replaceable>-compiled.specifics</replaceable>
|
|
part should be set in the
|
|
<makevar>PKGNAMESUFFIX</makevar> variable.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The version string should follow a dash
|
|
(<literal>-</literal>) and be a period-separated list of
|
|
integers and single lowercase alphabetics. In
|
|
particular, it is not permissible to have another dash
|
|
inside the version string. The only exception is the
|
|
string <literal>pl</literal> (meaning
|
|
<quote>patchlevel</quote>), which can be used
|
|
<emphasis>only</emphasis> when there are no major and
|
|
minor version numbers in the software. If the software
|
|
version has strings like <quote>alpha</quote>,
|
|
<quote>beta</quote>, <quote>rc</quote>, or
|
|
<quote>pre</quote>, take the first letter and put it
|
|
immediately after a period. If the version string
|
|
continues after those names, the numbers should follow
|
|
the single alphabet without an extra period between
|
|
them.</para>
|
|
|
|
<para>The idea is to make it easier to sort ports by
|
|
looking at the version string. In particular, make sure
|
|
version number components are always delimited by a
|
|
period, and if the date is part of the string, use the
|
|
<literal>0.0.<replaceable>yyyy</replaceable>.<replaceable>mm</replaceable>.<replaceable>dd</replaceable></literal>
|
|
format, not
|
|
<literal><replaceable>dd</replaceable>.<replaceable>mm</replaceable>.<replaceable>yyyy</replaceable></literal>
|
|
or the non-Y2K compliant
|
|
<literal><replaceable>yy</replaceable>.<replaceable>mm</replaceable>.<replaceable>dd</replaceable></literal>
|
|
format. It is important to prefix the version with
|
|
<literal>0.0.</literal> in case a release with an actual
|
|
version number is made, which would of course be
|
|
numerically less than
|
|
<literal><replaceable>yyyy</replaceable></literal>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Here are some (real) examples on how to convert the name
|
|
as called by the software authors to a suitable package
|
|
name:</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="6">
|
|
<thead>
|
|
<row>
|
|
<entry>Distribution Name</entry>
|
|
<entry><makevar>PKGNAMEPREFIX</makevar></entry>
|
|
<entry><makevar>PORTNAME</makevar></entry>
|
|
<entry><makevar>PKGNAMESUFFIX</makevar></entry>
|
|
<entry><makevar>PORTVERSION</makevar></entry>
|
|
<entry>Reason</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>mule-2.2.2</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>mule</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>2.2.2</entry>
|
|
<entry>No changes required</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>EmiClock-1.0.2</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>emiclock</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>1.0.2</entry>
|
|
<entry>No uppercase names for single programs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rdist-1.3alpha</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>rdist</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>1.3.a</entry>
|
|
<entry>No strings like <literal>alpha</literal>
|
|
allowed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>es-0.9-beta1</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>es</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>0.9.b1</entry>
|
|
<entry>No strings like <literal>beta</literal>
|
|
allowed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>mailman-2.0rc3</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>mailman</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>2.0.r3</entry>
|
|
<entry>No strings like <literal>rc</literal>
|
|
allowed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>v3.3beta021.src</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>tiff</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>3.3</entry>
|
|
<entry>What the heck was that anyway?</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>tvtwm</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>tvtwm</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>pl11</entry>
|
|
<entry>Version string always required</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>piewm</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>piewm</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>1.0</entry>
|
|
<entry>Version string always required</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>xvgr-2.10pl1</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>xvgr</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>2.10.1</entry>
|
|
<entry><literal>pl</literal> allowed only when no
|
|
major/minor version numbers</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>gawk-2.15.6</entry>
|
|
<entry>ja-</entry>
|
|
<entry>gawk</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>2.15.6</entry>
|
|
<entry>Japanese language version</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>psutils-1.13</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>psutils</entry>
|
|
<entry>-letter</entry>
|
|
<entry>1.13</entry>
|
|
<entry>Paper size hardcoded at package build
|
|
time</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>pkfonts</entry>
|
|
<entry>(empty)</entry>
|
|
<entry>pkfonts</entry>
|
|
<entry>300</entry>
|
|
<entry>1.0</entry>
|
|
<entry>Package for 300dpi fonts</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>If there is absolutely no trace of version information
|
|
in the original source and it is unlikely that the original
|
|
author will ever release another version, just set the
|
|
version string to <literal>1.0</literal> (like the
|
|
<literal>piewm</literal> example above). Otherwise, ask the
|
|
original author or use the date string
|
|
(<literal>0.0.<replaceable>yyyy</replaceable>.<replaceable>mm</replaceable>.<replaceable>dd</replaceable></literal>)
|
|
as the version.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-categories">
|
|
<title>Categorization</title>
|
|
|
|
<sect2>
|
|
<title><makevar>CATEGORIES</makevar></title>
|
|
|
|
<para>When a package is created, it is put under
|
|
<filename>/usr/ports/packages/All</filename> and links are
|
|
made from one or more subdirectories of
|
|
<filename>/usr/ports/packages</filename>. The names of
|
|
these subdirectories are specified by the variable
|
|
<makevar>CATEGORIES</makevar>. It is intended to make life
|
|
easier for the user when he is wading through the pile of
|
|
packages on the FTP site or the CDROM. Please take a look
|
|
at the <link linkend="porting-categories">current list of
|
|
categories</link> and pick the ones that are suitable for
|
|
your port.</para>
|
|
|
|
<para>This list also determines where in the ports tree the
|
|
port is imported. If you put more than one category here,
|
|
it is assumed that the port files will be put in the
|
|
subdirectory with the name in the first category. See <link
|
|
linkend="choosing-categories">below</link> for more
|
|
discussion about how to pick the right categories.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="porting-categories">
|
|
<title>Current List of Categories</title>
|
|
|
|
<para>Here is the current list of port categories. Those
|
|
marked with an asterisk (<literal>*</literal>) are
|
|
<emphasis>virtual</emphasis> categories—those that do
|
|
not have a corresponding subdirectory in the ports tree.
|
|
They are only used as secondary categories, and only for
|
|
search purposes.</para>
|
|
|
|
<note>
|
|
<para>For non-virtual categories, you will find a one-line
|
|
description in the <makevar>COMMENT</makevar> in that
|
|
subdirectory's <filename>Makefile</filename>.</para>
|
|
</note>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Category</entry>
|
|
<entry>Description</entry>
|
|
<entry>Notes</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><filename>accessibility</filename></entry>
|
|
<entry>Ports to help disabled users.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>afterstep*</filename></entry>
|
|
<entry>Ports to support the <ulink
|
|
url="http://www.afterstep.org">AfterStep</ulink>
|
|
window manager.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>arabic</filename></entry>
|
|
<entry>Arabic language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>archivers</filename></entry>
|
|
<entry>Archiving tools.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>astro</filename></entry>
|
|
<entry>Astronomical ports.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>audio</filename></entry>
|
|
<entry>Sound support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>benchmarks</filename></entry>
|
|
<entry>Benchmarking utilities.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>biology</filename></entry>
|
|
<entry>Biology-related software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>cad</filename></entry>
|
|
<entry>Computer aided design tools.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>chinese</filename></entry>
|
|
<entry>Chinese language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>comms</filename></entry>
|
|
<entry>Communication software.</entry>
|
|
<entry>Mostly software to talk to your serial
|
|
port.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>converters</filename></entry>
|
|
<entry>Character code converters.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>databases</filename></entry>
|
|
<entry>Databases.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>deskutils</filename></entry>
|
|
<entry>Things that used to be on the desktop before
|
|
computers were invented.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>devel</filename></entry>
|
|
<entry>Development utilities.</entry>
|
|
<entry>Do not put libraries here just because they are
|
|
libraries—unless they truly do not belong
|
|
anywhere else, they should not be in this
|
|
category.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>dns</filename></entry>
|
|
<entry>DNS-related software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>docs*</filename></entry>
|
|
<entry>Meta-ports for FreeBSD documentation.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>editors</filename></entry>
|
|
<entry>General editors.</entry>
|
|
<entry>Specialized editors go in the section for those
|
|
tools (e.g., a mathematical-formula editor will go
|
|
in <filename>math</filename>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>elisp*</filename></entry>
|
|
<entry>Emacs-lisp ports.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>emulators</filename></entry>
|
|
<entry>Emulators for other operating systems.</entry>
|
|
<entry>Terminal emulators do <emphasis>not</emphasis>
|
|
belong here—X-based ones should go to
|
|
<filename>x11</filename> and text-based ones to
|
|
either <filename>comms</filename> or
|
|
<filename>misc</filename>, depending on the exact
|
|
functionality.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>finance</filename></entry>
|
|
<entry>Monetary, financial and related
|
|
applications.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>french</filename></entry>
|
|
<entry>French language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>ftp</filename></entry>
|
|
<entry>FTP client and server utilities.</entry>
|
|
<entry>If your port speaks both FTP and HTTP, put it
|
|
in <filename>ftp</filename> with a secondary
|
|
category of <filename>www</filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>games</filename></entry>
|
|
<entry>Games.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>geography*</filename></entry>
|
|
<entry>Geography-related software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>german</filename></entry>
|
|
<entry>German language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>gnome*</filename></entry>
|
|
<entry>Ports from the <ulink
|
|
url="http://www.gnome.org">GNOME</ulink>
|
|
Project.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>gnustep*</filename></entry>
|
|
<entry>Software related to the GNUstep desktop
|
|
environment.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>graphics</filename></entry>
|
|
<entry>Graphics utilities.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>hamradio*</filename></entry>
|
|
<entry>Software for amateur radio.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>haskell*</filename></entry>
|
|
<entry>Software related to the Haskell
|
|
language.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>hebrew</filename></entry>
|
|
<entry>Hebrew language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>hungarian</filename></entry>
|
|
<entry>Hungarian language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>ipv6*</filename></entry>
|
|
<entry>IPv6 related software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>irc</filename></entry>
|
|
<entry>Internet Relay Chat utilities.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>japanese</filename></entry>
|
|
<entry>Japanese language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>java</filename></entry>
|
|
<entry>Software related to the Java™
|
|
language.</entry>
|
|
<entry>The <filename>java</filename> category must
|
|
not be the only one for a port. Save for ports
|
|
directly related to the Java language, porters are
|
|
also encouraged not to use <filename>java</filename>
|
|
as the main category of a port.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>kde*</filename></entry>
|
|
<entry>Ports from the <ulink
|
|
url="http://www.kde.org">KDE</ulink>
|
|
Project.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>kld*</filename></entry>
|
|
<entry>Kernel loadable modules.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>korean</filename></entry>
|
|
<entry>Korean language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>lang</filename></entry>
|
|
<entry>Programming languages.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>linux*</filename></entry>
|
|
<entry>Linux applications and support
|
|
utilities.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>lisp*</filename></entry>
|
|
<entry>Software related to the Lisp language.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>mail</filename></entry>
|
|
<entry>Mail software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>math</filename></entry>
|
|
<entry>Numerical computation software and other
|
|
utilities for mathematics.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>mbone*</filename></entry>
|
|
<entry>MBone applications.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>misc</filename></entry>
|
|
<entry>Miscellaneous utilities</entry>
|
|
<entry>Basically things that do not belong anywhere
|
|
else. If at all possible, try to find a better
|
|
category for your port than <literal>misc</literal>,
|
|
as ports tend to get overlooked in here.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>multimedia</filename></entry>
|
|
<entry>Multimedia software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>net</filename></entry>
|
|
<entry>Miscellaneous networking software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>net-im</filename></entry>
|
|
<entry>Instant messaging software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>net-mgmt</filename></entry>
|
|
<entry>Networking management software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>net-p2p</filename></entry>
|
|
<entry>Peer to peer network applications.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>news</filename></entry>
|
|
<entry>USENET news software.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>palm</filename></entry>
|
|
<entry>Software support for the <ulink
|
|
url="http://www.palm.com/">Palm™</ulink>
|
|
series.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>parallel*</filename></entry>
|
|
<entry>Applications dealing with parallelism in
|
|
computing.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>pear*</filename></entry>
|
|
<entry>Ports related to the Pear PHP
|
|
framework.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>perl5*</filename></entry>
|
|
<entry>Ports that require
|
|
<application>Perl</application> version 5 to
|
|
run.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>plan9*</filename></entry>
|
|
<entry>Various programs from <ulink
|
|
url="http://www.cs.bell-labs.com/plan9dist/">Plan9</ulink>.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>polish</filename></entry>
|
|
<entry>Polish language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>ports-mgmt</filename></entry>
|
|
<entry>Ports for managing, installing and developing
|
|
FreeBSD ports and packages.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>portuguese</filename></entry>
|
|
<entry>Portuguese language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>print</filename></entry>
|
|
<entry>Printing software.</entry>
|
|
<entry>Desktop publishing tools
|
|
(previewers, etc.) belong here too.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>python*</filename></entry>
|
|
<entry>Software related to the <ulink
|
|
url="http://www.python.org/">Python</ulink>
|
|
language.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>ruby*</filename></entry>
|
|
<entry>Software related to the <ulink
|
|
url="http://www.ruby-lang.org/">Ruby</ulink>
|
|
language.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>rubygems*</filename></entry>
|
|
<entry>Ports of <ulink
|
|
url="http://www.rubygems.org/">RubyGems</ulink>
|
|
packages.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>russian</filename></entry>
|
|
<entry>Russian language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>scheme*</filename></entry>
|
|
<entry>Software related to the Scheme
|
|
language.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>science</filename></entry>
|
|
<entry>Scientific ports that do not fit into other
|
|
categories such as <filename>astro</filename>,
|
|
<filename>biology</filename> and
|
|
<filename>math</filename>.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>security</filename></entry>
|
|
<entry>Security utilities.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>shells</filename></entry>
|
|
<entry>Command line shells.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>spanish*</filename></entry>
|
|
<entry>Spanish language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>sysutils</filename></entry>
|
|
<entry>System utilities.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>tcl*</filename></entry>
|
|
<entry>Ports that use Tcl to run.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>textproc</filename></entry>
|
|
<entry>Text processing utilities.</entry>
|
|
<entry>It does not include desktop publishing tools,
|
|
which go to <filename>print</filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>tk*</filename></entry>
|
|
<entry>Ports that use Tk to run.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>ukrainian</filename></entry>
|
|
<entry>Ukrainian language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>vietnamese</filename></entry>
|
|
<entry>Vietnamese language support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>windowmaker*</filename></entry>
|
|
<entry>Ports to support the WindowMaker window
|
|
manager.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>www</filename></entry>
|
|
<entry>Software related to the World Wide Web.</entry>
|
|
<entry>HTML language
|
|
support belongs here too.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11</filename></entry>
|
|
<entry>The X Window System and friends.</entry>
|
|
<entry>This category is only for software that
|
|
directly supports the window system. Do not put
|
|
regular X applications here; most of them should go
|
|
into other <filename>x11-*</filename> categories
|
|
(see below). If your port <emphasis>is</emphasis>
|
|
an X application, define <makevar>USE_XLIB</makevar>
|
|
(implied by <makevar>USE_IMAKE</makevar>) and put it
|
|
in the appropriate category.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-clocks</filename></entry>
|
|
<entry>X11 clocks.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-drivers</filename></entry>
|
|
<entry>X11 drivers.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-fm</filename></entry>
|
|
<entry>X11 file managers.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-fonts</filename></entry>
|
|
<entry>X11 fonts and font utilities.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-servers</filename></entry>
|
|
<entry>X11 servers.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-themes</filename></entry>
|
|
<entry>X11 themes.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-toolkits</filename></entry>
|
|
<entry>X11 toolkits.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>x11-wm</filename></entry>
|
|
<entry>X11 window managers.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>xfce*</filename></entry>
|
|
<entry>Ports related to the <ulink
|
|
url="http://www.xfce.org/">Xfce</ulink> desktop
|
|
environment.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><filename>zope*</filename></entry>
|
|
<entry><ulink url="http://www.zope.org/">Zope</ulink>
|
|
support.</entry>
|
|
<entry></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</sect2>
|
|
|
|
<sect2 id="choosing-categories">
|
|
<title>Choosing the Right Category</title>
|
|
|
|
<para>As many of the categories overlap, you often have to
|
|
choose which of the categories should be the primary
|
|
category of your port. There are several rules that govern
|
|
this issue. Here is the list of priorities, in decreasing
|
|
order of precedence:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The first category must be a physical category (see
|
|
<link linkend="porting-categories">above</link>). This
|
|
is necessary to make the packaging work. Virtual
|
|
categories and physical categories may be intermixed
|
|
after that.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Language specific categories always come first. For
|
|
example, if your port installs Japanese X11 fonts, then
|
|
your <makevar>CATEGORIES</makevar> line would read
|
|
<filename>japanese x11-fonts</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Specific categories are listed before less-specific
|
|
ones. For instance, an HTML editor should be listed as
|
|
<filename>www editors</filename>, not the other way
|
|
around. Also, you should not list
|
|
<filename>net</filename> when the port belongs to any of
|
|
<filename>irc</filename>, <filename>mail</filename>,
|
|
<filename>news</filename>,
|
|
<filename>security</filename>, or
|
|
<filename>www</filename>, as <filename>net</filename> is
|
|
included implicitly.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>x11</filename> is used as a secondary
|
|
category only when the primary category is a natural
|
|
language. In particular, you should not put
|
|
<filename>x11</filename> in the category line for X
|
|
applications.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><application>Emacs</application> modes should be
|
|
placed in the same ports category as the application
|
|
supported by the mode, not in
|
|
<filename>editors</filename>. For example, an
|
|
<application>Emacs</application> mode to edit source
|
|
files of some programming language should go into
|
|
<filename>lang</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ports which install loadable kernel modules should
|
|
have the virtual category <filename>kld</filename> in
|
|
their <makevar>CATEGORIES</makevar> line.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>misc</filename> should not appear with any
|
|
other non-virtual category. If you have
|
|
<literal>misc</literal> with something else in your
|
|
<makevar>CATEGORIES</makevar> line, that means you can
|
|
safely delete <literal>misc</literal> and just put the
|
|
port in that other subdirectory!</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If your port truly does not belong anywhere else,
|
|
put it in <filename>misc</filename>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>If you are not sure about the category, please put a
|
|
comment to that effect in your &man.send-pr.1; submission so
|
|
we can discuss it before we import it. If you are a
|
|
committer, send a note to the &a.ports; so we can discuss it
|
|
first. Too often, new ports are imported to the wrong
|
|
category only to be moved right away. This causes
|
|
unnecessary and undesirable bloat in the master source
|
|
repository.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="proposing-categories">
|
|
<title>Proposing a New Category</title>
|
|
|
|
<para>As the Ports Collection has grown over time, various new
|
|
categories have been introduced. New categories can either
|
|
be <emphasis>virtual</emphasis> categories—those that
|
|
do not have a corresponding subdirectory in the ports
|
|
tree— or <emphasis>physical</emphasis>
|
|
categories—those that do. The following text
|
|
discusses the issues involved in creating a new physical
|
|
category so that you can understand them before you propose
|
|
one.</para>
|
|
|
|
<para>Our existing practice has been to avoid creating a new
|
|
physical category unless either a large number of ports
|
|
would logically belong to it, or the ports that would belong
|
|
to it are a logically distinct group that is of limited
|
|
general interest (for instance, categories related to spoken
|
|
human languages), or preferably both.</para>
|
|
|
|
<para>The rationale for this is that such a change creates a
|
|
<ulink url="&url.articles.committers-guide;/#ports"> fair
|
|
amount of work</ulink> for both the committers and also
|
|
for all users who track changes to the Ports Collection. In
|
|
addition, proposed category changes just naturally seem to
|
|
attract controversy. (Perhaps this is because there is no
|
|
clear consensus on when a category is <quote>too
|
|
big</quote>, nor whether categories should lend themselves
|
|
to browsing (and thus what number of categories would be an
|
|
ideal number), and so forth.)</para>
|
|
|
|
<para>Here is the procedure:</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Propose the new category on &a.ports;. You should
|
|
include a detailed rationale for the new category,
|
|
including why you feel the existing categories are not
|
|
sufficient, and the list of existing ports proposed to
|
|
move. (If there are new ports pending in
|
|
<application>GNATS</application> that would fit this
|
|
category, list them too.) If you are the maintainer
|
|
and/or submitter, respectively, mention that as it may
|
|
help you to make your case.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Participate in the discussion.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>If it seems that there is support for your idea,
|
|
file a PR which includes both the rationale and the list
|
|
of existing ports that need to be moved. Ideally, this
|
|
PR should also include patches for the following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><filename>Makefile</filename>s for the
|
|
new ports once they are repocopied</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>Makefile</filename> for the
|
|
new category</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>Makefile</filename> for the
|
|
old ports' categories</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>Makefile</filename>s for ports
|
|
that depend on the old ports</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(for extra credit, you can include the other
|
|
files that have to change, as per the procedure
|
|
in the Committer's Guide.)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Since it affects the ports infrastructure and
|
|
involves not only performing repo-copies but also
|
|
possibly running regression tests on the build cluster,
|
|
the PR should be assigned to the &a.portmgr;.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>If that PR is approved, a committer will need to
|
|
follow the rest of the procedure that is <ulink
|
|
url="&url.articles.committers-guide;/article.html#PORTS">
|
|
outlined in the Committer's Guide</ulink>.</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>Proposing a new virtual category should be similar to
|
|
the above but much less involved, since no ports will
|
|
actually have to move. In this case, the only patches to
|
|
include in the PR would be those to add the new category to
|
|
the <makevar>CATEGORIES</makevar> of the affected
|
|
ports.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="proposing-reorg">
|
|
<title>Proposing Reorganizing All the Categories</title>
|
|
|
|
<para>Occasionally someone proposes reorganizing the
|
|
categories with either a 2-level structure, or some other
|
|
kind of keyword structure. To date, nothing has come of any
|
|
of these proposals because, while they are very easy to
|
|
make, the effort involved to retrofit the entire existing
|
|
ports collection with any kind of reorganization is daunting
|
|
to say the very least. Please read the history of these
|
|
proposals in the mailing list archives before you post this
|
|
idea; furthermore, you should be prepared to be challenged
|
|
to offer a working prototype.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-distfiles">
|
|
<title>The Distribution Files</title>
|
|
|
|
<para>The second part of the <filename>Makefile</filename>
|
|
describes the files that must be downloaded in order to build
|
|
the port, and where they can be downloaded from.</para>
|
|
|
|
<sect2>
|
|
<title><makevar>DISTVERSION/DISTNAME</makevar></title>
|
|
|
|
<para><makevar>DISTNAME</makevar> is the name of the port as
|
|
called by the authors of the software.
|
|
<makevar>DISTNAME</makevar> defaults to
|
|
<literal>${PORTNAME}-${PORTVERSION}</literal>, so override
|
|
it only if necessary. <makevar>DISTNAME</makevar> is only
|
|
used in two places. First, the distribution file list
|
|
(<makevar>DISTFILES</makevar>) defaults to
|
|
<makevar>${DISTNAME}</makevar><makevar>${EXTRACT_SUFX}</makevar>.
|
|
Second, the distribution file is expected to extract into a
|
|
subdirectory named <makevar>WRKSRC</makevar>, which defaults
|
|
to
|
|
<filename>work/<makevar>${DISTNAME}</makevar></filename>.</para>
|
|
|
|
<para>Some vendor's distribution names which do not fit into
|
|
the <literal>${PORTNAME}-${PORTVERSION}</literal>-scheme can
|
|
be handled automatically by setting
|
|
<makevar>DISTVERSION</makevar>.
|
|
<makevar>PORTVERSION</makevar> and
|
|
<makevar>DISTNAME</makevar> will be derived automatically,
|
|
but can of course be overridden. The following table lists
|
|
some examples:</para>
|
|
|
|
<informaltable frame="none" pgwide="0">
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry><makevar>DISTVERSION</makevar></entry>
|
|
<entry><makevar>PORTVERSION</makevar></entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>0.7.1d</entry>
|
|
<entry>0.7.1.d</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>10Alpha3</entry>
|
|
<entry>10.a3</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>3Beta7-pre2</entry>
|
|
<entry>3.b7.p2</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>8:f_17</entry>
|
|
<entry>8f.17</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<note>
|
|
<para><makevar>PKGNAMEPREFIX</makevar> and
|
|
<makevar>PKGNAMESUFFIX</makevar> do not affect
|
|
<makevar>DISTNAME</makevar>. Also note that if
|
|
<makevar>WRKSRC</makevar> is equal to
|
|
<filename>work/<makevar>${PORTNAME}-${PORTVERSION}</makevar></filename>
|
|
while the original source archive is named something other
|
|
than
|
|
<makevar>${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}</makevar>,
|
|
you should probably leave <makevar>DISTNAME</makevar>
|
|
alone— you are better off defining
|
|
<makevar>DISTFILES</makevar> than having to set both
|
|
<makevar>DISTNAME</makevar> and <makevar>WRKSRC</makevar>
|
|
(and possibly <makevar>EXTRACT_SUFX</makevar>).</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>MASTER_SITES</makevar></title>
|
|
|
|
<para>Record the directory part of the FTP/HTTP-URL pointing
|
|
at the original tarball in <makevar>MASTER_SITES</makevar>.
|
|
Do not forget the trailing slash
|
|
(<filename>/</filename>)!</para>
|
|
|
|
<para>The <command>make</command> macros will try to use this
|
|
specification for grabbing the distribution file with
|
|
<makevar>FETCH</makevar> if they cannot find it already on
|
|
the system.</para>
|
|
|
|
<para>It is recommended that you put multiple sites on this
|
|
list, preferably from different continents. This will
|
|
safeguard against wide-area network problems. We are even
|
|
planning to add support for automatically determining the
|
|
closest master site and fetching from there; having multiple
|
|
sites will go a long way towards helping this effort.</para>
|
|
|
|
<para>If the original tarball is part of one of the popular
|
|
archives such as SourceForge, GNU, or Perl CPAN, you may be
|
|
able refer to those sites in an easy compact form using
|
|
<makevar>MASTER_SITE_<replaceable>*</replaceable></makevar>
|
|
(e.g., <makevar>MASTER_SITE_SOURCEFORGE</makevar>,
|
|
<makevar>MASTER_SITE_GNU</makevar> and
|
|
<makevar>MASTER_SITE_PERL_CPAN</makevar>). Simply set
|
|
<makevar>MASTER_SITES</makevar> to one of these variables
|
|
and <makevar>MASTER_SITE_SUBDIR</makevar> to the path within
|
|
the archive. Here is an example:</para>
|
|
|
|
<programlisting>MASTER_SITES= ${MASTER_SITE_GNU}
|
|
MASTER_SITE_SUBDIR= make</programlisting>
|
|
|
|
<para>Or you can use a condensed format:</para>
|
|
|
|
<programlisting>MASTER_SITES= GNU/make</programlisting>
|
|
|
|
<para>These variables are defined in
|
|
<filename>/usr/ports/Mk/bsd.sites.mk</filename>. There are
|
|
new entries added all the time, so make sure to check the
|
|
latest version of this file before submitting a port.</para>
|
|
|
|
<para>Several <emphasis>magic</emphasis> macros exist for
|
|
popular sites with a predictable directory structure. For
|
|
these, just use the abbreviation and the system will try to
|
|
guess the correct subdirectory for you.</para>
|
|
|
|
<programlisting>MASTER_SITES= SF</programlisting>
|
|
|
|
<para>If the guess is incorrect, it can be overridden as
|
|
follows.</para>
|
|
|
|
<programlisting>MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}</programlisting>
|
|
|
|
<para>This can be also written as</para>
|
|
<programlisting>MASTER_SITES= SF
|
|
MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION}</programlisting>
|
|
|
|
<table frame="none">
|
|
<title>Popular Magic <makevar>MASTER_SITES</makevar>
|
|
Macros</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Macro</entry>
|
|
<entry>Assumed subdirectory</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>APACHE_JAKARTA</makevar></entry>
|
|
<entry><makevar>/dist/jakarta/${PORTNAME:S,-,,/,}/source</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>BERLIOS</makevar></entry>
|
|
<entry><makevar>/${PORTNAME:L}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>CHEESESHOP</makevar></entry>
|
|
<entry><makevar>/packages/source/source/${DISTNAME:C/(.).*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>DEBIAN</makevar></entry>
|
|
<entry><makevar>/debian/pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>GCC</makevar></entry>
|
|
<entry><makevar>/pub/gcc/releases/${DISTNAME}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>GNOME</makevar></entry>
|
|
<entry><makevar>/pub/GNOME/sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>GNU</makevar></entry>
|
|
<entry><makevar>/gnu/${PORTNAME}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>MOZDEV</makevar></entry>
|
|
<entry><makevar>/pub/mozdev/${PORTNAME:L}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PERL_CPAN</makevar></entry>
|
|
<entry><makevar>/pub/CPAN/modules/by-module/${PORTNAME:C/-.*//}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYTHON</makevar></entry>
|
|
<entry><makevar>/ftp/python/${PYTHON_PORTVERSION:C/rc[0-9]//}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RUBYFORGE</makevar></entry>
|
|
<entry><makevar>/${PORTNAME:L}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>SAVANNAH</makevar></entry>
|
|
<entry><makevar>/${PORTNAME:L}</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>SF</makevar></entry>
|
|
<entry><makevar>/project/${PORTNAME:L}/${PORTNAME:L}/${PORTVERSION}</makevar></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>EXTRACT_SUFX</makevar></title>
|
|
|
|
<para>If you have one distribution file, and it uses an odd
|
|
suffix to indicate the compression mechanism, set
|
|
<makevar>EXTRACT_SUFX</makevar>.</para>
|
|
|
|
<para>For example, if the distribution file was named
|
|
<filename>foo.tgz</filename> instead of the more normal
|
|
<filename>foo.tar.gz</filename>, you would write:</para>
|
|
|
|
<programlisting>DISTNAME= foo
|
|
EXTRACT_SUFX= .tgz</programlisting>
|
|
|
|
<para>The <makevar>USE_BZIP2</makevar>,
|
|
<makevar>USE_XZ</makevar> and
|
|
<makevar>USE_ZIP</makevar> variables automatically set
|
|
<makevar>EXTRACT_SUFX</makevar> to
|
|
<literal>.tar.bz2</literal>, <literal>.tar.xz</literal>
|
|
or <literal>.zip</literal> as necessary. If neither of
|
|
these are set then <makevar>EXTRACT_SUFX</makevar>
|
|
defaults to <literal>.tar.gz</literal>.</para>
|
|
|
|
<note>
|
|
<para>You never need to set both
|
|
<makevar>EXTRACT_SUFX</makevar> and
|
|
<makevar>DISTFILES</makevar>.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>DISTFILES</makevar></title>
|
|
|
|
<para>Sometimes the names of the files to be downloaded have
|
|
no resemblance to the name of the port. For example, it
|
|
might be called <filename>source.tar.gz</filename> or
|
|
similar. In other cases the application's source code might
|
|
be in several different archives, all of which must be
|
|
downloaded.</para>
|
|
|
|
<para>If this is the case, set <makevar>DISTFILES</makevar> to
|
|
be a space separated list of all the files that must be
|
|
downloaded.</para>
|
|
|
|
<programlisting>DISTFILES= source1.tar.gz source2.tar.gz</programlisting>
|
|
|
|
<para>If not explicitly set, <makevar>DISTFILES</makevar>
|
|
defaults to
|
|
<literal>${DISTNAME}${EXTRACT_SUFX}</literal>.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>EXTRACT_ONLY</makevar></title>
|
|
|
|
<para>If only some of the <makevar>DISTFILES</makevar> must be
|
|
extracted—for example, one of them is the source code,
|
|
while another is an uncompressed document—list the
|
|
filenames that must be extracted in
|
|
<makevar>EXTRACT_ONLY</makevar>.</para>
|
|
|
|
<programlisting>DISTFILES= source.tar.gz manual.html
|
|
EXTRACT_ONLY= source.tar.gz</programlisting>
|
|
|
|
<para>If <emphasis>none</emphasis> of the
|
|
<makevar>DISTFILES</makevar> should be uncompressed then set
|
|
<makevar>EXTRACT_ONLY</makevar> to the empty string.</para>
|
|
|
|
<programlisting>EXTRACT_ONLY=</programlisting>
|
|
</sect2>
|
|
|
|
<sect2 id="porting-patchfiles">
|
|
<title><makevar>PATCHFILES</makevar></title>
|
|
|
|
<para>If your port requires some additional patches that are
|
|
available by FTP or HTTP, set <makevar>PATCHFILES</makevar>
|
|
to the names of the files and <makevar>PATCH_SITES</makevar>
|
|
to the URL of the directory that contains them (the format
|
|
is the same as <makevar>MASTER_SITES</makevar>).</para>
|
|
|
|
<para>If the patch is not relative to the top of the source
|
|
tree (i.e., <makevar>WRKSRC</makevar>) because it contains
|
|
some extra pathnames, set
|
|
<makevar>PATCH_DIST_STRIP</makevar> accordingly. For
|
|
instance, if all the pathnames in the patch have an extra
|
|
<literal>foozolix-1.0/</literal> in front of the filenames,
|
|
then set <literal>PATCH_DIST_STRIP=-p1</literal>.</para>
|
|
|
|
<para>Do not worry if the patches are compressed; they will be
|
|
decompressed automatically if the filenames end with
|
|
<filename>.gz</filename> or <filename>.Z</filename>.</para>
|
|
|
|
<para>If the patch is distributed with some other files, such
|
|
as documentation, in a <command>gzip</command>ped tarball,
|
|
you cannot just use <makevar>PATCHFILES</makevar>. If that
|
|
is the case, add the name and the location of the patch
|
|
tarball to <makevar>DISTFILES</makevar> and
|
|
<makevar>MASTER_SITES</makevar>. Then, use the
|
|
<makevar>EXTRA_PATCHES</makevar> variable to point to those
|
|
files and <filename>bsd.port.mk</filename> will
|
|
automatically apply them for you. In particular, do
|
|
<emphasis>not</emphasis> copy patch files into the
|
|
<makevar>PATCHDIR</makevar> directory—that directory
|
|
may not be writable.</para>
|
|
|
|
<note>
|
|
<para>The tarball will have been extracted alongside the
|
|
regular source by then, so there is no need to explicitly
|
|
extract it if it is a regular <command>gzip</command>ped
|
|
or <command>compress</command>ed tarball. If you do the
|
|
latter, take extra care not to overwrite something that
|
|
already exists in that directory. Also, do not forget to
|
|
add a command to remove the copied patch in the
|
|
<maketarget>pre-clean</maketarget> target.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 id="porting-master-sites-n">
|
|
<title>Multiple Distribution Files or Patches from Different
|
|
Sites and Subdirectories
|
|
(<literal>MASTER_SITES:n</literal>)</title>
|
|
|
|
<para>(Consider this to be a somewhat <quote>advanced
|
|
topic</quote>; those new to this document may wish to skip
|
|
this section at first).</para>
|
|
|
|
<para>This section has information on the fetching mechanism
|
|
known as both <literal>MASTER_SITES:n</literal> and
|
|
<literal>MASTER_SITES_NN</literal>. We will refer to this
|
|
mechanism as <literal>MASTER_SITES:n</literal>.</para>
|
|
|
|
<para>A little background first. OpenBSD has a neat feature
|
|
inside the <makevar>DISTFILES</makevar> and
|
|
<makevar>PATCHFILES</makevar> variables which allows files
|
|
and patches to be postfixed with <literal>:n</literal>
|
|
identifiers. Here, <literal>n</literal> can be both
|
|
<literal>[0-9]</literal> and denote a group designation.
|
|
For example:</para>
|
|
|
|
<programlisting>DISTFILES= alpha:0 beta:1</programlisting>
|
|
|
|
<para>In OpenBSD, distribution file <filename>alpha</filename>
|
|
will be associated with variable
|
|
<makevar>MASTER_SITES0</makevar> instead of our common
|
|
<makevar>MASTER_SITES</makevar> and
|
|
<filename>beta</filename> with
|
|
<makevar>MASTER_SITES1</makevar>.</para>
|
|
|
|
<para>This is a very interesting feature which can decrease
|
|
that endless search for the correct download site.</para>
|
|
|
|
<para>Just picture 2 files in <makevar>DISTFILES</makevar> and
|
|
20 sites in <makevar>MASTER_SITES</makevar>, the sites slow
|
|
as hell where <filename>beta</filename> is carried by all
|
|
sites in <makevar>MASTER_SITES</makevar>, and
|
|
<filename>alpha</filename> can only be found in the 20th
|
|
site. It would be such a waste to check all of them if the
|
|
maintainer knew this beforehand, would it not? Not a good
|
|
start for that lovely weekend!</para>
|
|
|
|
<para>Now that you have the idea, just imagine more
|
|
<makevar>DISTFILES</makevar> and more
|
|
<makevar>MASTER_SITES</makevar>. Surely our
|
|
<quote>distfiles survey meister</quote> would appreciate the
|
|
relief to network strain that this would bring.</para>
|
|
|
|
<para>In the next sections, information will follow on the
|
|
FreeBSD implementation of this idea. We improved a bit on
|
|
OpenBSD's concept.</para>
|
|
|
|
<sect3>
|
|
<title>Simplified Information</title>
|
|
|
|
<para>This section tells you how to quickly prepare fine
|
|
grained fetching of multiple distribution files and
|
|
patches from different sites and subdirectories. We
|
|
describe here a case of simplified
|
|
<literal>MASTER_SITES:n</literal> usage. This will be
|
|
sufficient for most scenarios. However, if you need
|
|
further information, you will have to refer to the next
|
|
section.</para>
|
|
|
|
<para>Some applications consist of multiple distribution
|
|
files that must be downloaded from a number of different
|
|
sites. For example,
|
|
<application>Ghostscript</application> consists of the
|
|
core of the program, and then a large number of driver
|
|
files that are used depending on the user's printer. Some
|
|
of these driver files are supplied with the core, but many
|
|
others must be downloaded from a variety of different
|
|
sites.</para>
|
|
|
|
<para>To support this, each entry in
|
|
<makevar>DISTFILES</makevar> may be followed by a colon
|
|
and a <quote>tag name</quote>. Each site listed in
|
|
<makevar>MASTER_SITES</makevar> is then followed by a
|
|
colon, and the tag that indicates which distribution files
|
|
should be downloaded from this site.</para>
|
|
|
|
<para>For example, consider an application with the source
|
|
split in two parts, <filename>source1.tar.gz</filename>
|
|
and <filename>source2.tar.gz</filename>, which must be
|
|
downloaded from two different sites. The port's
|
|
<filename>Makefile</filename> would include lines like
|
|
<xref
|
|
linkend="ports-master-sites-n-example-simple-use-one-file-per-site"/>.</para>
|
|
|
|
<example
|
|
id="ports-master-sites-n-example-simple-use-one-file-per-site">
|
|
<title>Simplified Use of <literal>MASTER_SITES:n</literal>
|
|
with One File Per Site</title>
|
|
|
|
<programlisting>MASTER_SITES= ftp://ftp.example1.com/:source1 \
|
|
ftp://ftp.example2.com/:source2
|
|
DISTFILES= source1.tar.gz:source1 \
|
|
source2.tar.gz:source2</programlisting>
|
|
</example>
|
|
|
|
<para>Multiple distribution files can have the same tag.
|
|
Continuing the previous example, suppose that there was a
|
|
third distfile, <filename>source3.tar.gz</filename>, that
|
|
should be downloaded from
|
|
<hostid>ftp.example2.com</hostid>. The
|
|
<filename>Makefile</filename> would then be written like
|
|
<xref
|
|
linkend="ports-master-sites-n-example-simple-use-more-than-one-file-per-site"/>.</para>
|
|
|
|
<example
|
|
id="ports-master-sites-n-example-simple-use-more-than-one-file-per-site">
|
|
<title>Simplified Use of <literal>MASTER_SITES:n</literal>
|
|
with More Than One File Per Site</title>
|
|
|
|
<programlisting>MASTER_SITES= ftp://ftp.example1.com/:source1 \
|
|
ftp://ftp.example2.com/:source2
|
|
DISTFILES= source1.tar.gz:source1 \
|
|
source2.tar.gz:source2 \
|
|
source3.tar.gz:source2</programlisting>
|
|
</example>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Detailed Information</title>
|
|
|
|
<para>Okay, so the previous section example did not reflect
|
|
your needs? In this section we will explain in detail
|
|
how the fine grained fetching mechanism
|
|
<literal>MASTER_SITES:n</literal> works and how you can
|
|
modify your ports to use it.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Elements can be postfixed with
|
|
<literal>:<replaceable>n</replaceable></literal> where
|
|
<replaceable>n</replaceable> is
|
|
<literal>[^:,]+</literal>, i.e.,
|
|
<replaceable>n</replaceable> could conceptually be any
|
|
alphanumeric string but we will limit it to
|
|
<literal>[a-zA-Z_][0-9a-zA-Z_]+</literal> for
|
|
now.</para>
|
|
|
|
<para>Moreover, string matching is case sensitive;
|
|
i.e., <literal>n</literal> is different from
|
|
<literal>N</literal>.</para>
|
|
|
|
<para>However, the following words cannot be used for
|
|
postfixing purposes since they yield special meaning:
|
|
<literal>default</literal>, <literal>all</literal> and
|
|
<literal>ALL</literal> (they are used internally in
|
|
item <xref
|
|
linkend="porting-master-sites-n-what-changes-in-port-targets"/>).
|
|
Furthermore, <literal>DEFAULT</literal> is a special
|
|
purpose word (check item <xref
|
|
linkend="porting-master-sites-n-DEFAULT-group"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Elements postfixed with <literal>:n</literal>
|
|
belong to the group <literal>n</literal>,
|
|
<literal>:m</literal> belong to group
|
|
<literal>m</literal> and so forth.</para>
|
|
</listitem>
|
|
|
|
<listitem id="porting-master-sites-n-DEFAULT-group">
|
|
<para>Elements without a postfix are groupless, i.e.,
|
|
they all belong to the special group
|
|
<literal>DEFAULT</literal>. If you postfix any
|
|
elements with <literal>DEFAULT</literal>, you are just
|
|
being redundant unless you want to have an element
|
|
belonging to both <literal>DEFAULT</literal> and other
|
|
groups at the same time (check item <xref
|
|
linkend="porting-master-sites-n-comma-operator"/>).</para>
|
|
|
|
<para>The following examples are equivalent but the
|
|
first one is preferred:</para>
|
|
|
|
<programlisting>MASTER_SITES= alpha</programlisting>
|
|
|
|
<programlisting>MASTER_SITES= alpha:DEFAULT</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Groups are not exclusive, an element may belong to
|
|
several different groups at the same time and a group
|
|
can either have either several different elements or
|
|
none at all. Repeated elements within the same group
|
|
will be simply that, repeated elements.</para>
|
|
</listitem>
|
|
|
|
<listitem id="porting-master-sites-n-comma-operator">
|
|
<para>When you want an element to belong to several
|
|
groups at the same time, you can use the comma
|
|
operator (<literal>,</literal>).</para>
|
|
|
|
<para>Instead of repeating it several times, each time
|
|
with a different postfix, we can list several groups
|
|
at once in a single postfix. For instance,
|
|
<literal>:m,n,o</literal> marks an element that
|
|
belongs to group <literal>m</literal>,
|
|
<literal>n</literal> and <literal>o</literal>.</para>
|
|
|
|
<para>All the following examples are equivalent but the
|
|
last one is preferred:</para>
|
|
|
|
<programlisting>MASTER_SITES= alpha alpha:SOME_SITE</programlisting>
|
|
|
|
<programlisting>MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE</programlisting>
|
|
|
|
<programlisting>MASTER_SITES= alpha:SOME_SITE,DEFAULT</programlisting>
|
|
|
|
<programlisting>MASTER_SITES= alpha:DEFAULT,SOME_SITE</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>All sites within a given group are sorted
|
|
according to <makevar>MASTER_SORT_AWK</makevar>. All
|
|
groups within <makevar>MASTER_SITES</makevar> and
|
|
<makevar>PATCH_SITES</makevar> are sorted as
|
|
well.</para>
|
|
</listitem>
|
|
|
|
<listitem id="porting-master-sites-n-group-semantics">
|
|
<para>Group semantics can be used in any of the
|
|
following variables <makevar>MASTER_SITES</makevar>,
|
|
<makevar>PATCH_SITES</makevar>,
|
|
<makevar>MASTER_SITE_SUBDIR</makevar>,
|
|
<makevar>PATCH_SITE_SUBDIR</makevar>,
|
|
<makevar>DISTFILES</makevar>, and
|
|
<makevar>PATCHFILES</makevar> according to the
|
|
following syntax:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>All <makevar>MASTER_SITES</makevar>,
|
|
<makevar>PATCH_SITES</makevar>,
|
|
<makevar>MASTER_SITE_SUBDIR</makevar> and
|
|
<makevar>PATCH_SITE_SUBDIR</makevar> elements must
|
|
be terminated with the forward slash
|
|
<literal>/</literal> character. If any elements
|
|
belong to any groups, the group postfix
|
|
<literal>:<replaceable>n</replaceable></literal>
|
|
must come right after the terminator
|
|
<literal>/</literal>. The
|
|
<literal>MASTER_SITES:n</literal> mechanism relies
|
|
on the existence of the terminator
|
|
<literal>/</literal> to avoid confusing elements
|
|
where a <literal>:n</literal> is a valid part of
|
|
the element with occurrences where
|
|
<literal>:n</literal> denotes group
|
|
<literal>n</literal>. For compatibility purposes,
|
|
since the <literal>/</literal> terminator was not
|
|
required before in both
|
|
<makevar>MASTER_SITE_SUBDIR</makevar> and
|
|
<makevar>PATCH_SITE_SUBDIR</makevar> elements, if
|
|
the postfix immediate preceding character is not
|
|
a <literal>/</literal> then <literal>:n</literal>
|
|
will be considered a valid part of the element
|
|
instead of a group postfix even if an element is
|
|
postfixed with <literal>:n</literal>. See both
|
|
<xref
|
|
linkend="ports-master-sites-n-example-detailed-use-master-site-subdir"/>
|
|
and <xref
|
|
linkend="ports-master-sites-n-example-detailed-use-complete-example-master-sites"/>.</para>
|
|
|
|
<example
|
|
id="ports-master-sites-n-example-detailed-use-master-site-subdir">
|
|
|
|
<title>Detailed Use of
|
|
<literal>MASTER_SITES:n</literal> in
|
|
<makevar>MASTER_SITE_SUBDIR</makevar></title>
|
|
|
|
<programlisting>MASTER_SITE_SUBDIR= old:n new/:NEW</programlisting>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Directories within group
|
|
<literal>DEFAULT</literal> ->
|
|
old:n</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Directories within group
|
|
<literal>NEW</literal> -> new</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</example>
|
|
|
|
<example
|
|
id="ports-master-sites-n-example-detailed-use-complete-example-master-sites">
|
|
<title>Detailed Use of
|
|
<literal>MASTER_SITES:n</literal> with Comma
|
|
Operator, Multiple Files, Multiple Sites and
|
|
Multiple Subdirectories</title>
|
|
|
|
<programlisting>MASTER_SITES= http://site1/%SUBDIR%/ http://site2/:DEFAULT \
|
|
http://site3/:group3 http://site4/:group4 \
|
|
http://site5/:group5 http://site6/:group6 \
|
|
http://site7/:DEFAULT,group6 \
|
|
http://site8/%SUBDIR%/:group6,group7 \
|
|
http://site9/:group8
|
|
DISTFILES= file1 file2:DEFAULT file3:group3 \
|
|
file4:group4,group5,group6 file5:grouping \
|
|
file6:group7
|
|
MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \
|
|
directory-one/:group6,DEFAULT \
|
|
directory</programlisting>
|
|
|
|
<para>The previous example results in the
|
|
following fine grained fetching. Sites are
|
|
listed in the exact order they will be
|
|
used.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><filename>file1</filename> will be
|
|
fetched from</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_OVERRIDE</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site1/directory-trial:1/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site1/directory-one/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site1/directory/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site2/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site7/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_BACKUP</makevar></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>file2</filename> will be
|
|
fetched exactly as
|
|
<filename>file1</filename> since they
|
|
both belong to the same group</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_OVERRIDE</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site1/directory-trial:1/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site1/directory-one/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site1/directory/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site2/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site7/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_BACKUP</makevar></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>file3</filename> will be
|
|
fetched from</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_OVERRIDE</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site3/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_BACKUP</makevar></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>file4</filename> will be
|
|
fetched from</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_OVERRIDE</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site4/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site5/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site6/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site7/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site8/directory-one/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_BACKUP</makevar></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>file5</filename> will be
|
|
fetched from</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_OVERRIDE</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_BACKUP</makevar></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><filename>file6</filename> will be
|
|
fetched from</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_OVERRIDE</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>http://site8/</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>MASTER_SITE_BACKUP</makevar></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</example>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How do I group one of the special variables from
|
|
<filename>bsd.sites.mk</filename>, e.g.,
|
|
<makevar>MASTER_SITE_SOURCEFORGE</makevar>?</para>
|
|
|
|
<para>See <xref
|
|
linkend="ports-master-sites-n-example-detailed-use-master-site-sourceforge"/>.</para>
|
|
|
|
<example
|
|
id="ports-master-sites-n-example-detailed-use-master-site-sourceforge">
|
|
<title>Detailed Use of
|
|
<literal>MASTER_SITES:n</literal> with
|
|
<makevar>MASTER_SITE_SOURCEFORGE</makevar></title>
|
|
|
|
<programlisting>MASTER_SITES= http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/}
|
|
DISTFILES= something.tar.gz:sourceforge</programlisting>
|
|
</example>
|
|
|
|
<para><filename>something.tar.gz</filename> will be
|
|
fetched from all sites within
|
|
<makevar>MASTER_SITE_SOURCEFORGE</makevar>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>How do I use this with <makevar>PATCH*</makevar>
|
|
variables?</para>
|
|
|
|
<para>All examples were done with
|
|
<makevar>MASTER*</makevar> variables but they work
|
|
exactly the same for <makevar>PATCH*</makevar> ones as
|
|
can be seen in <xref
|
|
linkend="ports-master-sites-n-example-detailed-use-patch-sites"/>.</para>
|
|
|
|
<example
|
|
id="ports-master-sites-n-example-detailed-use-patch-sites">
|
|
<title>Simplified Use of
|
|
<literal>MASTER_SITES:n</literal> with
|
|
<makevar>PATCH_SITES</makevar></title>
|
|
|
|
<programlisting>PATCH_SITES= http://site1/ http://site2/:test
|
|
PATCHFILES= patch1:test</programlisting>
|
|
</example>
|
|
</listitem>
|
|
</orderedlist>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>What Does Change for Ports? What Does Not?</title>
|
|
|
|
<orderedlist numeration="lowerroman">
|
|
<listitem>
|
|
<para>All current ports remain the same. The
|
|
<literal>MASTER_SITES:n</literal> feature code is only
|
|
activated if there are elements postfixed with
|
|
<literal>:<replaceable>n</replaceable></literal> like
|
|
elements according to the aforementioned syntax rules,
|
|
especially as shown in item <xref
|
|
linkend="porting-master-sites-n-group-semantics"/>.</para>
|
|
</listitem>
|
|
|
|
<listitem
|
|
id="porting-master-sites-n-what-changes-in-port-targets">
|
|
<para>The port targets remain the same:
|
|
<maketarget>checksum</maketarget>,
|
|
<maketarget>makesum</maketarget>,
|
|
<maketarget>patch</maketarget>,
|
|
<maketarget>configure</maketarget>,
|
|
<maketarget>build</maketarget>, etc. With the obvious
|
|
exceptions of <maketarget>do-fetch</maketarget>,
|
|
<maketarget>fetch-list</maketarget>,
|
|
<maketarget>master-sites</maketarget> and
|
|
<maketarget>patch-sites</maketarget>.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><maketarget>do-fetch</maketarget>: deploys the
|
|
new grouping postfixed
|
|
<makevar>DISTFILES</makevar> and
|
|
<makevar>PATCHFILES</makevar> with their matching
|
|
group elements within both
|
|
<makevar>MASTER_SITES</makevar> and
|
|
<makevar>PATCH_SITES</makevar> which use matching
|
|
group elements within both
|
|
<makevar>MASTER_SITE_SUBDIR</makevar> and
|
|
<makevar>PATCH_SITE_SUBDIR</makevar>. Check <xref
|
|
linkend="ports-master-sites-n-example-detailed-use-complete-example-master-sites"/>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><maketarget>fetch-list</maketarget>: works
|
|
like old <maketarget>fetch-list</maketarget> with
|
|
the exception that it groups just like
|
|
<maketarget>do-fetch</maketarget>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><maketarget>master-sites</maketarget> and
|
|
<maketarget>patch-sites</maketarget>:
|
|
(incompatible with older versions) only return the
|
|
elements of group <literal>DEFAULT</literal>; in
|
|
fact, they execute targets
|
|
<maketarget>master-sites-default</maketarget> and
|
|
<maketarget>patch-sites-default</maketarget>
|
|
respectively.</para>
|
|
|
|
<para>Furthermore, using target either
|
|
<maketarget>master-sites-all</maketarget> or
|
|
<maketarget>patch-sites-all</maketarget> is
|
|
preferred to directly checking either
|
|
<maketarget>MASTER_SITES</maketarget> or
|
|
<maketarget>PATCH_SITES</maketarget>. Also,
|
|
directly checking is not guaranteed to work in any
|
|
future versions. Check item <xref
|
|
linkend="porting-master-sites-n-new-port-targets-master-sites-all"/>
|
|
for more information on these new port
|
|
targets.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>New port targets</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>There are
|
|
<maketarget>master-sites-<replaceable>n</replaceable></maketarget>
|
|
and
|
|
<maketarget>patch-sites-<replaceable>n</replaceable></maketarget>
|
|
targets which will list the elements of the
|
|
respective group <replaceable>n</replaceable>
|
|
within <makevar>MASTER_SITES</makevar> and
|
|
<makevar>PATCH_SITES</makevar> respectively. For
|
|
instance, both
|
|
<maketarget>master-sites-DEFAULT</maketarget> and
|
|
<maketarget>patch-sites-DEFAULT</maketarget> will
|
|
return the elements of group
|
|
<literal>DEFAULT</literal>,
|
|
<maketarget>master-sites-test</maketarget> and
|
|
<maketarget>patch-sites-test</maketarget> of group
|
|
<literal>test</literal>, and thereon.</para>
|
|
</listitem>
|
|
|
|
<listitem
|
|
id="porting-master-sites-n-new-port-targets-master-sites-all">
|
|
<para>There are new targets
|
|
<maketarget>master-sites-all</maketarget> and
|
|
<maketarget>patch-sites-all</maketarget> which do
|
|
the work of the old
|
|
<maketarget>master-sites</maketarget> and
|
|
<maketarget>patch-sites</maketarget> ones. They
|
|
return the elements of all groups as if they all
|
|
belonged to the same group with the caveat that it
|
|
lists as many
|
|
<makevar>MASTER_SITE_BACKUP</makevar> and
|
|
<makevar>MASTER_SITE_OVERRIDE</makevar> as there
|
|
are groups defined within either
|
|
<makevar>DISTFILES</makevar> or
|
|
<makevar>PATCHFILES</makevar>; respectively for
|
|
<maketarget>master-sites-all</maketarget> and
|
|
<maketarget>patch-sites-all</maketarget>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</orderedlist>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>DIST_SUBDIR</makevar></title>
|
|
|
|
<para>Do not let your port clutter
|
|
<filename>/usr/ports/distfiles</filename>. If your port
|
|
requires a lot of files to be fetched, or contains a file
|
|
that has a name that might conflict with other ports (e.g.,
|
|
<filename>Makefile</filename>), set
|
|
<makevar>DIST_SUBDIR</makevar> to the name of the port
|
|
(<literal>${PORTNAME}</literal> or
|
|
<literal>${PKGNAMEPREFIX}${PORTNAME}</literal> should work
|
|
fine). This will change <makevar>DISTDIR</makevar> from the
|
|
default <filename>/usr/ports/distfiles</filename> to
|
|
<filename>/usr/ports/distfiles/<makevar>DIST_SUBDIR</makevar></filename>,
|
|
and in effect puts everything that is required for your port
|
|
into that subdirectory.</para>
|
|
|
|
<para>It will also look at the subdirectory with the same name
|
|
on the backup master site at
|
|
<filename>ftp.FreeBSD.org</filename>. (Setting
|
|
<makevar>DISTDIR</makevar> explicitly in your
|
|
<makevar>Makefile</makevar> will not accomplish this, so
|
|
please use <makevar>DIST_SUBDIR</makevar>.)</para>
|
|
|
|
<note>
|
|
<para>This does not affect the
|
|
<makevar>MASTER_SITES</makevar> you define in your
|
|
<filename>Makefile</filename>.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>ALWAYS_KEEP_DISTFILES</makevar></title>
|
|
|
|
<para>If your port uses binary distfiles and has a license
|
|
that requires that the source code is provided with packages
|
|
distributed in binary form, e.g., GPL,
|
|
<makevar>ALWAYS_KEEP_DISTFILES</makevar> will instruct the
|
|
&os; build cluster to keep a copy of the files specified in
|
|
<makevar>DISTFILES</makevar>. Users of these ports will
|
|
generally not need these files, so it is a good idea to only
|
|
add the source distfiles to <makevar>DISTFILES</makevar>
|
|
when <makevar>PACKAGE_BUILDING</makevar> is defined.</para>
|
|
|
|
<example
|
|
id="ports-master-sites-n-example-always-keep-distfiles">
|
|
<title>Use of
|
|
<makevar>ALWAYS_KEEP_DISTFILES</makevar></title>
|
|
|
|
<programlisting>.if defined(PACKAGE_BUILDING)
|
|
DISTFILES+= <replaceable>foo.tar.gz</replaceable>
|
|
ALWAYS_KEEP_DISTFILES= yes
|
|
.endif</programlisting>
|
|
</example>
|
|
|
|
<para>When adding extra files to <makevar>DISTFILES</makevar>,
|
|
make sure you also add them to
|
|
<filename>distinfo</filename>. Also, the additional files
|
|
will normally be extracted into <makevar>WRKDIR</makevar> as
|
|
well, which for some ports may lead to undesirable side
|
|
effects and require special handling.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-maintainer">
|
|
<title><makevar>MAINTAINER</makevar></title>
|
|
|
|
<para>Set your mail-address here. Please. <!-- smiley
|
|
--><emphasis>:-)</emphasis></para>
|
|
|
|
<para>Note that only a single address without the comment part
|
|
is allowed as a <makevar>MAINTAINER</makevar> value. The
|
|
format used should be <literal>user@hostname.domain</literal>.
|
|
Please do not include any descriptive text such as your real
|
|
name in this entry—that merely confuses
|
|
<filename>bsd.port.mk</filename>.</para>
|
|
|
|
<para>The maintainer is responsible for keeping the port up to
|
|
date, and ensuring the port works correctly.
|
|
For a detailed description of the responsibilities of a port
|
|
maintainer, refer to the <ulink
|
|
url="&url.articles.contributing-ports;/maintain-port.html">The
|
|
challenge for port maintainers</ulink> section.</para>
|
|
|
|
<para>Changes to the port will be sent to the maintainer of a
|
|
port for review and approval before being committed. If the
|
|
maintainer does not respond to an update request after two
|
|
weeks (excluding major public holidays), then that is
|
|
considered a maintainer timeout, and the update may be made
|
|
without explicit maintainer approval. If the maintainer does
|
|
not respond within three months, then that maintainer is
|
|
considered absent without leave, and can be replaced as the
|
|
maintainer of the particular port in question. Exceptions to
|
|
this are anything maintained by the &a.portmgr;, or the
|
|
&a.security-officer;. No unauthorized commits may ever be
|
|
made to ports maintained by those groups.</para>
|
|
|
|
<para>We reserve the right to modify the maintainer's submission
|
|
to better match existing policies and style of the Ports
|
|
Collection without explicit blessing from the submitter.
|
|
Also, large infrastructural changes can result in a port being
|
|
modified without the maintainer's consent. These kinds of
|
|
changes will never affect the port's functionality.</para>
|
|
|
|
<para>The &a.portmgr; reserves the right to revoke or override
|
|
anyone's maintainership for any reason, and the
|
|
&a.security-officer; reserves the right to revoke or override
|
|
maintainership for security reasons.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-comment">
|
|
<title><makevar>COMMENT</makevar></title>
|
|
|
|
<para>This is a one-line description of the port.
|
|
Please respect the following rules:</para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Try to keep the COMMENT value at no longer than 70
|
|
characters, as this line will be used by the &man.pkg.info.1;
|
|
utility to display a one-line summary of the port;</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Do <emphasis>not</emphasis> include the package name
|
|
(or version number of the software);</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The comment should begin with a capital and end without a
|
|
period;</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Do not start with an indefinite article (i.e. A or An);</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Names are capitalized (e.g. Apache, JavaScript, Perl);</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>For lists of words use the Oxford comma (e.g. green,
|
|
red<emphasis>,</emphasis> and blue);</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Spell check the text.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
<para>Here is an example:</para>
|
|
|
|
<programlisting>COMMENT= Cat chasing a mouse all over the screen</programlisting>
|
|
|
|
<para>The COMMENT variable should immediately follow the
|
|
MAINTAINER variable in the
|
|
<filename>Makefile</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-depend">
|
|
<title>Dependencies</title>
|
|
|
|
<para>Many ports depend on other ports. This is a very
|
|
convenient feature of most Unix-like operating systems,
|
|
including &os;. Multiple ports can share a common dependency,
|
|
rather than bundling that dependency with every port or
|
|
package that needs it. There are seven variables that can be
|
|
used to ensure that all the required bits will be on the
|
|
user's machine. There are also some pre-supported dependency
|
|
variables for common cases, plus a few more to control the
|
|
behavior of dependencies.</para>
|
|
|
|
<sect2>
|
|
<title><makevar>LIB_DEPENDS</makevar></title>
|
|
|
|
<para>This variable specifies the shared libraries this port
|
|
depends on. It is a list of
|
|
<replaceable>lib</replaceable>:<replaceable>dir</replaceable><optional><replaceable>:target</replaceable></optional>
|
|
tuples where <replaceable>lib</replaceable> is the name of
|
|
the shared library, <replaceable>dir</replaceable> is the
|
|
directory in which to find it in case it is not available,
|
|
and <replaceable>target</replaceable> is the target to call
|
|
in that directory. For example,</para>
|
|
|
|
<programlisting>LIB_DEPENDS= jpeg:${PORTSDIR}/graphics/jpeg</programlisting>
|
|
|
|
<para>will check for a shared jpeg library with any version,
|
|
and descend into the
|
|
<filename>graphics/jpeg</filename> subdirectory of your
|
|
ports tree to build and install it if it is not found. The
|
|
<replaceable>target</replaceable> part can be omitted if it
|
|
is equal to <makevar>DEPENDS_TARGET</makevar> (which
|
|
defaults to <literal>install</literal>).</para>
|
|
|
|
<note>
|
|
<para>The <replaceable>lib</replaceable> part is a regular
|
|
expression which is being looked up in the
|
|
<command>ldconfig -r</command> output. Values such as
|
|
<literal>intl.9</literal> and <literal>intl.[5-7]</literal>
|
|
are allowed. The first pattern,
|
|
<literal>intl.9</literal>, will match only version 9 of
|
|
intl, while
|
|
<literal>intl.[5-7]</literal>, will match any of:
|
|
<literal>intl.5</literal>, <literal>intl.6</literal> or
|
|
<literal>intl.7</literal>.</para>
|
|
</note>
|
|
|
|
<para>The dependency is checked twice, once from within the
|
|
<maketarget>extract</maketarget> target and then from within
|
|
the <maketarget>install</maketarget> target. Also, the name
|
|
of the dependency is put into the package so that
|
|
&man.pkg.add.1; will automatically install it if it is not
|
|
on the user's system.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>RUN_DEPENDS</makevar></title>
|
|
|
|
<para>This variable specifies executables or files this port
|
|
depends on during run-time. It is a list of
|
|
<replaceable>path</replaceable>:<replaceable>dir</replaceable><optional><replaceable>:target</replaceable></optional>
|
|
tuples where <replaceable>path</replaceable> is the name of
|
|
the executable or file, <replaceable>dir</replaceable> is
|
|
the directory in which to find it in case it is not
|
|
available, and <replaceable>target</replaceable> is the
|
|
target to call in that directory. If
|
|
<replaceable>path</replaceable> starts with a slash
|
|
(<literal>/</literal>), it is treated as a file and its
|
|
existence is tested with <command>test -e</command>;
|
|
otherwise, it is assumed to be an executable, and
|
|
<command>which -s</command> is used to determine if the
|
|
program exists in the search path.</para>
|
|
|
|
<para>For example,</para>
|
|
|
|
<programlisting>RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:${PORTSDIR}/news/inn \
|
|
xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr</programlisting>
|
|
|
|
<para>will check if the file or directory
|
|
<filename>/usr/local/news/bin/innd</filename> exists, and build
|
|
and install it from the <filename>news/inn</filename>
|
|
subdirectory of the ports tree if it is not found. It will
|
|
also see if an executable called
|
|
<command>xmlcatmgr</command> is in the search path, and
|
|
descend into the <filename>textproc/xmlcatmgr</filename>
|
|
subdirectory of your ports tree to build and install it if
|
|
it is not found.</para>
|
|
|
|
<note>
|
|
<para>In this case, <command>innd</command> is actually an
|
|
executable; if an executable is in a place that is not
|
|
expected to be in the search path, you should use the full
|
|
pathname.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>The official search <envar>PATH</envar> used on the
|
|
ports build cluster is</para>
|
|
|
|
<programlisting>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</programlisting>
|
|
</note>
|
|
|
|
<para>The dependency is checked from within the
|
|
<maketarget>install</maketarget> target. Also, the name of
|
|
the dependency is put into the package so that
|
|
&man.pkg.add.1; will automatically install it if it is not
|
|
on the user's system. The <replaceable>target</replaceable>
|
|
part can be omitted if it is the same as
|
|
<makevar>DEPENDS_TARGET</makevar>.</para>
|
|
|
|
<para>A quite common situation is when
|
|
<makevar>RUN_DEPENDS</makevar> is literally the same as
|
|
<makevar>BUILD_DEPENDS</makevar>, especially if ported
|
|
software is written in a scripted language or if it requires
|
|
the same build and run-time environment. In this
|
|
case, it is both tempting and intuitive to directly
|
|
assign one to the other:</para>
|
|
|
|
<programlisting>RUN_DEPENDS= ${BUILD_DEPENDS}</programlisting>
|
|
|
|
<para>However, such assignment can pollute run-time
|
|
dependencies with entries not defined in the port's original
|
|
<makevar>BUILD_DEPENDS</makevar>. This happens because of
|
|
&man.make.1;'s lazy evaluation of variable assignment.
|
|
Consider a <filename>Makefile</filename> with
|
|
<makevar>USE_<replaceable>*</replaceable></makevar>
|
|
variables, which are processed by
|
|
<filename>ports/Mk/bsd.*.mk</filename> to augment initial
|
|
build dependencies. For example,
|
|
<literal>USE_GMAKE=yes</literal> adds <filename
|
|
role="package">devel/gmake</filename> to
|
|
<makevar>BUILD_DEPENDS</makevar>. To prevent such
|
|
additional dependencies from polluting
|
|
<makevar>RUN_DEPENDS</makevar>, take care to assign with
|
|
expansion, i.e., expand the value before assigning it to the
|
|
variable:</para>
|
|
|
|
<programlisting>RUN_DEPENDS:= ${BUILD_DEPENDS}</programlisting>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>BUILD_DEPENDS</makevar></title>
|
|
|
|
<para>This variable specifies executables or files this port
|
|
requires to build. Like <makevar>RUN_DEPENDS</makevar>, it
|
|
is a list of
|
|
<replaceable>path</replaceable>:<replaceable>dir</replaceable><optional><replaceable>:target</replaceable></optional>
|
|
tuples. For example,</para>
|
|
|
|
<programlisting>BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip</programlisting>
|
|
|
|
<para>will check for an executable called
|
|
<command>unzip</command>, and descend into the
|
|
<filename>archivers/unzip</filename> subdirectory of your
|
|
ports tree to build and install it if it is not
|
|
found.</para>
|
|
|
|
<note>
|
|
<para><quote>build</quote> here means everything from
|
|
extraction to compilation. The dependency is checked from
|
|
within the <maketarget>extract</maketarget> target. The
|
|
<replaceable>target</replaceable> part can be omitted if
|
|
it is the same as <makevar>DEPENDS_TARGET</makevar></para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>FETCH_DEPENDS</makevar></title>
|
|
|
|
<para>This variable specifies executables or files this port
|
|
requires to fetch. Like the previous two, it is a list of
|
|
<replaceable>path</replaceable>:<replaceable>dir</replaceable><optional><replaceable>:target</replaceable></optional>
|
|
tuples. For example,</para>
|
|
|
|
<programlisting>FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2</programlisting>
|
|
|
|
<para>will check for an executable called
|
|
<command>ncftp2</command>, and descend into the
|
|
<filename>net/ncftp2</filename> subdirectory of your ports
|
|
tree to build and install it if it is not found.</para>
|
|
|
|
<para>The dependency is checked from within the
|
|
<maketarget>fetch</maketarget> target. The
|
|
<replaceable>target</replaceable> part can be omitted if it
|
|
is the same as <makevar>DEPENDS_TARGET</makevar>.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>EXTRACT_DEPENDS</makevar></title>
|
|
|
|
<para>This variable specifies executables or files this port
|
|
requires for extraction. Like the previous, it is a list of
|
|
<replaceable>path</replaceable>:<replaceable>dir</replaceable><optional><replaceable>:target</replaceable></optional>
|
|
tuples. For example,</para>
|
|
|
|
<programlisting>EXTRACT_DEPENDS= unzip:${PORTSDIR}/archivers/unzip</programlisting>
|
|
|
|
<para>will check for an executable called
|
|
<command>unzip</command>, and descend into the
|
|
<filename>archivers/unzip</filename> subdirectory of your
|
|
ports tree to build and install it if it is not
|
|
found.</para>
|
|
|
|
<para>The dependency is checked from within the
|
|
<maketarget>extract</maketarget> target. The
|
|
<replaceable>target</replaceable> part can be omitted if it
|
|
is the same as <makevar>DEPENDS_TARGET</makevar>.</para>
|
|
|
|
<note>
|
|
<para>Use this variable only if the extraction does not
|
|
already work (the default assumes <command>gzip</command>)
|
|
and cannot be made to work using
|
|
<makevar>USE_ZIP</makevar> or <makevar>USE_BZIP2</makevar>
|
|
described in <xref linkend="use-vars"/>.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>PATCH_DEPENDS</makevar></title>
|
|
|
|
<para>This variable specifies executables or files this port
|
|
requires to patch. Like the previous, it is a list of
|
|
<replaceable>path</replaceable>:<replaceable>dir</replaceable><optional><replaceable>:target</replaceable></optional>
|
|
tuples. For example,</para>
|
|
|
|
<programlisting>PATCH_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract</programlisting>
|
|
|
|
<para>will descend into the <filename>java/jfc</filename>
|
|
subdirectory of your ports tree to extract it.</para>
|
|
|
|
<para>The dependency is checked from within the
|
|
<maketarget>patch</maketarget> target. The
|
|
<replaceable>target</replaceable> part can be omitted if it
|
|
is the same as <makevar>DEPENDS_TARGET</makevar>.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="use-vars">
|
|
<title><makevar>USE_<replaceable>*</replaceable></makevar></title>
|
|
|
|
<para>Several variables exist to define
|
|
common dependencies shared by many ports. Their
|
|
use is optional, but helps to reduce the verbosity of
|
|
the port <filename>Makefile</filename>s. Each of them is
|
|
styled as
|
|
<makevar>USE_<replaceable>*</replaceable></makevar>.
|
|
These variables may be used only in the port
|
|
<filename>Makefile</filename>s and
|
|
<filename>ports/Mk/bsd.*.mk</filename>. They are not meant
|
|
for user-settable options — use
|
|
<makevar>PORT_OPTIONS</makevar> for that purpose.</para>
|
|
|
|
<note>
|
|
<para>It is <emphasis>always</emphasis> incorrect to set any
|
|
<makevar>USE_<replaceable>*</replaceable></makevar> in
|
|
<filename>/etc/make.conf</filename>. For instance,
|
|
setting</para>
|
|
|
|
<programlisting>USE_GCC=3.4</programlisting>
|
|
|
|
<para>would add a dependency on gcc34 for every port,
|
|
including gcc34 itself!</para>
|
|
</note>
|
|
|
|
<table frame="none">
|
|
<title>The
|
|
<makevar>USE_<replaceable>*</replaceable></makevar>
|
|
Variables</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Means</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_BZIP2</makevar></entry>
|
|
<entry>The port's tarballs are compressed with
|
|
<command>bzip2</command>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_ZIP</makevar></entry>
|
|
<entry>The port's tarballs are compressed with
|
|
<command>zip</command>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_BISON</makevar></entry>
|
|
<entry>The port uses <command>bison</command> for
|
|
building.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_CDRTOOLS</makevar></entry>
|
|
<entry>The port requires
|
|
<application>cdrecord</application> either from
|
|
<filename
|
|
role="package">sysutils/cdrtools</filename> or
|
|
<filename
|
|
role="package">sysutils/cdrtools-cjk</filename>,
|
|
according to the user's preference.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_GCC</makevar></entry>
|
|
<entry>The port requires a specific version of
|
|
<command>gcc</command> to build. The exact version
|
|
can be specified with value such as
|
|
<literal>3.4</literal>. The minimal required
|
|
version can be specified as <literal>3.4+</literal>.
|
|
The <command>gcc</command> from the base system is
|
|
used when it satisfies the requested version,
|
|
otherwise an appropriate <command>gcc</command> is
|
|
compiled from ports and the <makevar>CC</makevar>
|
|
and <makevar>CXX</makevar> variables are
|
|
adjusted.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Variables related to <application>gmake</application>
|
|
and the <filename>configure</filename> script are described
|
|
in <xref linkend="building"/>, while
|
|
<application>autoconf</application>,
|
|
<application>automake</application> and
|
|
<application>libtool</application> are described in <xref
|
|
linkend="using-autotools"/>.
|
|
<application>Perl</application> related variables are
|
|
described in <xref linkend="using-perl"/>. X11 variables are
|
|
listed in <xref linkend="using-x11"/>. <xref
|
|
linkend="using-gnome"/> deals with GNOME and <xref
|
|
linkend="using-kde"/> with KDE related variables. <xref
|
|
linkend="using-java"/> documents Java variables, while
|
|
<xref linkend="using-php"/> contains information on
|
|
<application>Apache</application>,
|
|
<application>PHP</application> and PEAR modules.
|
|
<application>Python</application> is discussed in <xref
|
|
linkend="using-python"/>, while
|
|
<application>Ruby</application> in <xref
|
|
linkend="using-ruby"/>. <xref linkend="using-sdl"/> provides
|
|
variables used for <application>SDL</application>
|
|
applications and finally, <xref linkend="using-xfce"/>
|
|
contains information on
|
|
<application>Xfce</application>.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Minimal Version of a Dependency</title>
|
|
|
|
<para>A minimal version of a dependency can be specified in
|
|
any <makevar>*_DEPENDS</makevar> variable except
|
|
<makevar>LIB_DEPENDS</makevar> using the following
|
|
syntax:</para>
|
|
|
|
<programlisting>p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy</programlisting>
|
|
|
|
<para>The first field contains a dependent package name, which
|
|
must match the entry in the package database, a comparison
|
|
sign, and a package version. The dependency is satisfied if
|
|
p5-Spiffy-0.26 or newer is installed on the machine.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Notes on Dependencies</title>
|
|
|
|
<para>As mentioned above, the default target to call when a
|
|
dependency is required is
|
|
<maketarget>DEPENDS_TARGET</maketarget>. It defaults to
|
|
<literal>install</literal>. This is a user variable; it is
|
|
never defined in a port's <filename>Makefile</filename>. If
|
|
your port needs a special way to handle a dependency, use
|
|
the <literal>:target</literal> part of the
|
|
<makevar>*_DEPENDS</makevar> variables instead of redefining
|
|
<makevar>DEPENDS_TARGET</makevar>.</para>
|
|
|
|
<para>When you type <command>make clean</command>, its
|
|
dependencies are automatically cleaned too. If you do not
|
|
wish this to happen, define the variable
|
|
<makevar>NOCLEANDEPENDS</makevar> in your environment. This
|
|
may be particularly desirable if the port has something that
|
|
takes a long time to rebuild in its dependency list, such as
|
|
KDE, GNOME or Mozilla.</para>
|
|
|
|
<para>To depend on another port unconditionally, use the
|
|
variable <makevar>${NONEXISTENT}</makevar> as the first
|
|
field of <makevar>BUILD_DEPENDS</makevar> or
|
|
<makevar>RUN_DEPENDS</makevar>. Use this only when you need
|
|
to get the source of the other port. You can often save
|
|
compilation time by specifying the target too. For
|
|
instance</para>
|
|
|
|
<programlisting>BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract</programlisting>
|
|
|
|
<para>will always descend to the <literal>jpeg</literal> port
|
|
and extract it.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Circular Dependencies Are Fatal</title>
|
|
|
|
<important>
|
|
<para>Do not introduce any circular dependencies into the
|
|
ports tree!</para>
|
|
</important>
|
|
|
|
<para>The ports building technology does not tolerate circular
|
|
dependencies. If you introduce one, you will have someone,
|
|
somewhere in the world, whose FreeBSD installation will
|
|
break almost immediately, with many others quickly to
|
|
follow. These can really be hard to detect; if in doubt,
|
|
before you make that change, make sure you have done the
|
|
following: <command>cd /usr/ports; make index</command>.
|
|
That process can be quite slow on older machines, but you
|
|
may be able to save a large number of people—including
|
|
yourself— a lot of grief in the process.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Problems Caused by Automatic Dependencies</title>
|
|
|
|
<para>Dependencies must be declared either explicitly or by
|
|
using the <link
|
|
linkend="makefile-options">OPTIONS framework</link>.
|
|
Using other methods like automatic detection complicates
|
|
indexing, which causes problems for port and package
|
|
management.</para>
|
|
|
|
<example>
|
|
<title>Wrong Declaration of an Optional Dependency</title>
|
|
|
|
<programlisting>.include <bsd.port.pre.mk>
|
|
|
|
.if exists(${LOCALBASE}/bin/foo)
|
|
LIB_DEPENDS= bar:${PORTSDIR}/foo/bar
|
|
.endif</programlisting>
|
|
</example>
|
|
|
|
<para>The problem with trying to automatically add
|
|
dependencies is that files and settings outside an
|
|
individual port can change at any time. For example: an
|
|
index is built, then a batch of ports are installed. But
|
|
one of the ports installs the tested file. The index is now
|
|
incorrect, because an installed port unexpectedly has a new
|
|
dependency. The index may still be wrong even after
|
|
rebuilding if other ports also determine their need for
|
|
dependencies based on the existence of other files.</para>
|
|
|
|
<example>
|
|
<title>Correct Declaration of an Optional Dependency</title>
|
|
|
|
<programlisting>OPTIONS_DEFINE= BAR
|
|
BAR_DESC= Enable bar support
|
|
|
|
.include <bsd.port.options.mk>
|
|
|
|
.if ${PORT_OPTIONS:MBAR}
|
|
LIB_DEPENDS= bar:${PORTSDIR}/foo/bar
|
|
.endif</programlisting>
|
|
</example>
|
|
|
|
<para>Testing option variables is the correct method. It will
|
|
not cause inconsistencies in the index of a batch of ports,
|
|
provided the options were defined prior to the index build.
|
|
Simple scripts can then be used to automate the building,
|
|
installation, and updating of these ports and their
|
|
packages.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="use-want">
|
|
<title><makevar>USE_</makevar> and
|
|
<makevar>WANT_</makevar></title>
|
|
|
|
<para><makevar>USE_</makevar> variables are set by the port
|
|
maintainer to define software on which this port depends. A
|
|
port that needs Firefox would set</para>
|
|
|
|
<programlisting>USE_FIREFOX= yes</programlisting>
|
|
|
|
<para>Some <makevar>USE_</makevar> variables can accept
|
|
version numbers or other parameters. For example, a port
|
|
that requires Apache 2.2 would set</para>
|
|
|
|
<programlisting>USE_APACHE= 22</programlisting>
|
|
|
|
<para>For more control over dependencies in some cases,
|
|
<makevar>WANT_</makevar> variables are available to more
|
|
precisely specify what is needed. For example, consider the
|
|
<filename role="package">mail/squirrelmail</filename> port.
|
|
This port needs some PHP modules, which are listed in the
|
|
<makevar>USE_PHP</makevar> variable:</para>
|
|
|
|
<programlisting>USE_PHP= session mhash gettext mbstring pcre openssl xml</programlisting>
|
|
|
|
<para>Those modules may be available in CLI or web versions,
|
|
so the web version is selected with a
|
|
<makevar>WANT_</makevar> variable:</para>
|
|
|
|
<programlisting>WANT_PHP_WEB= yes</programlisting>
|
|
|
|
<para>Available <makevar>USE_</makevar> and
|
|
<makevar>WANT_</makevar> variables are defined in the files
|
|
in <filename>/usr/ports/Mk</filename>.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-masterdir">
|
|
<title><makevar>MASTERDIR</makevar></title>
|
|
|
|
<para>If your port needs to build slightly different versions of
|
|
packages by having a variable (for instance, resolution, or
|
|
paper size) take different values, create one subdirectory per
|
|
package to make it easier for users to see what to do, but try
|
|
to share as many files as possible between ports. Typically
|
|
you only need a very short <filename>Makefile</filename> in
|
|
all but one of the directories if you use variables cleverly.
|
|
In the sole <filename>Makefile</filename>, you can use
|
|
<makevar>MASTERDIR</makevar> to specify the directory where
|
|
the rest of the files are. Also, use a variable as part of
|
|
<link
|
|
linkend="porting-pkgname"><makevar>PKGNAMESUFFIX</makevar></link>
|
|
so the packages will have different names.</para>
|
|
|
|
<para>This will be best demonstrated by an example. This is
|
|
part of <filename>japanese/xdvi300/Makefile</filename>;</para>
|
|
|
|
<programlisting>PORTNAME= xdvi
|
|
PORTVERSION= 17
|
|
PKGNAMEPREFIX= ja-
|
|
PKGNAMESUFFIX= ${RESOLUTION}
|
|
:
|
|
# default
|
|
RESOLUTION?= 300
|
|
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
|
|
${RESOLUTION} != 300 && ${RESOLUTION} != 400
|
|
@${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
|
|
@${ECHO_MSG} "Possible values are: 118, 240, 300 (default) and 400."
|
|
@${FALSE}
|
|
.endif</programlisting>
|
|
|
|
<para><filename role="package">japanese/xdvi300</filename> also
|
|
has all the regular patches, package files, etc. If you type
|
|
<command>make</command> there, it will take the default value
|
|
for the resolution (300) and build the port normally.</para>
|
|
|
|
<para>As for other resolutions, this is the
|
|
<emphasis>entire</emphasis>
|
|
<filename>xdvi118/Makefile</filename>:</para>
|
|
|
|
<programlisting>RESOLUTION= 118
|
|
MASTERDIR= ${.CURDIR}/../xdvi300
|
|
|
|
.include "${MASTERDIR}/Makefile"</programlisting>
|
|
|
|
<para>(<filename>xdvi240/Makefile</filename> and
|
|
<filename>xdvi400/Makefile</filename> are similar). The
|
|
<makevar>MASTERDIR</makevar> definition tells
|
|
<filename>bsd.port.mk</filename> that the regular set of
|
|
subdirectories like <makevar>FILESDIR</makevar> and
|
|
<makevar>SCRIPTDIR</makevar> are to be found under
|
|
<filename>xdvi300</filename>. The
|
|
<literal>RESOLUTION=118</literal> line will override the
|
|
<literal>RESOLUTION=300</literal> line in
|
|
<filename>xdvi300/Makefile</filename> and the port will be
|
|
built with resolution set to 118.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-manpages">
|
|
<title>Man Pages</title>
|
|
|
|
<para>The <makevar>MAN[1-9LN]</makevar> variables will
|
|
automatically add any manpages to
|
|
<filename>pkg-plist</filename> (this means you must
|
|
<emphasis>not</emphasis> list manpages in the
|
|
<filename>pkg-plist</filename>—see <link
|
|
linkend="plist-sub">generating PLIST</link> for more). It
|
|
also makes the install stage automatically compress or
|
|
uncompress manpages depending on the setting of
|
|
<makevar>NO_MANCOMPRESS</makevar> in
|
|
<filename>/etc/make.conf</filename>.</para>
|
|
|
|
<para>If your port tries to install multiple names for manpages
|
|
using symlinks or hardlinks, you must use the
|
|
<makevar>MLINKS</makevar> variable to identify these. The
|
|
link installed by your port will be destroyed and recreated by
|
|
<filename>bsd.port.mk</filename> to make sure it points to the
|
|
correct file. Any manpages listed in MLINKS must not be
|
|
listed in the <filename>pkg-plist</filename>.</para>
|
|
|
|
<para>To specify whether the manpages are compressed upon
|
|
installation, use the <makevar>MANCOMPRESSED</makevar>
|
|
variable. This variable can take three values,
|
|
<literal>yes</literal>, <literal>no</literal> and
|
|
<literal>maybe</literal>. <literal>yes</literal> means
|
|
manpages are already installed compressed,
|
|
<literal>no</literal> means they are not, and
|
|
<literal>maybe</literal> means the software already respects
|
|
the value of <makevar>NO_MANCOMPRESS</makevar> so
|
|
<filename>bsd.port.mk</filename> does not have to do anything
|
|
special.</para>
|
|
|
|
<para><makevar>MANCOMPRESSED</makevar> is automatically set to
|
|
<literal>yes</literal> if <makevar>USE_IMAKE</makevar> is set
|
|
and <makevar>NO_INSTALL_MANPAGES</makevar> is not set, and to
|
|
<literal>no</literal> otherwise. You do not have to
|
|
explicitly define it unless the default is not suitable for
|
|
your port.</para>
|
|
|
|
<para>If your port anchors its man tree somewhere other than
|
|
<makevar>PREFIX</makevar>, you can use the
|
|
<makevar>MANPREFIX</makevar> to set it. Also, if only
|
|
manpages in certain sections go in a non-standard place, such
|
|
as some <literal>perl</literal> modules ports, you can set
|
|
individual man paths using
|
|
<makevar>MAN<replaceable>sect</replaceable>PREFIX</makevar>
|
|
(where <replaceable>sect</replaceable> is one of
|
|
<literal>1-9</literal>, <literal>L</literal> or
|
|
<literal>N</literal>).</para>
|
|
|
|
<para>If your manpages go to language-specific subdirectories,
|
|
set the name of the languages to <makevar>MANLANG</makevar>.
|
|
The value of this variable defaults to <literal>""</literal>
|
|
(i.e., English only).</para>
|
|
|
|
<para>Here is an example that puts it all together.</para>
|
|
|
|
<programlisting>MAN1= foo.1
|
|
MAN3= bar.3
|
|
MAN4= baz.4
|
|
MLINKS= foo.1 alt-name.8
|
|
MANLANG= "" ja
|
|
MAN3PREFIX= ${PREFIX}/share/foobar
|
|
MANCOMPRESSED= yes</programlisting>
|
|
|
|
<para>This states that six files are installed by this
|
|
port;</para>
|
|
|
|
<programlisting>${MANPREFIX}/man/man1/foo.1.gz
|
|
${MANPREFIX}/man/ja/man1/foo.1.gz
|
|
${PREFIX}/share/foobar/man/man3/bar.3.gz
|
|
${PREFIX}/share/foobar/man/ja/man3/bar.3.gz
|
|
${MANPREFIX}/man/man4/baz.4.gz
|
|
${MANPREFIX}/man/ja/man4/baz.4.gz</programlisting>
|
|
|
|
<para>Additionally
|
|
<filename>${MANPREFIX}/man/man8/alt-name.8.gz</filename> may
|
|
or may not be installed by your port. Regardless, a symlink
|
|
will be made to join the foo(1) manpage and alt-name(8)
|
|
manpage.</para>
|
|
|
|
<para>If only some manpages are translated, you can use several
|
|
variables dynamically created from <makevar>MANLANG</makevar>
|
|
content:</para>
|
|
|
|
<programlisting>MANLANG= "" de ja
|
|
MAN1= foo.1
|
|
MAN1_EN= bar.1
|
|
MAN3_DE= baz.3</programlisting>
|
|
|
|
<para>This translates into this list of files:</para>
|
|
|
|
<programlisting>${MANPREFIX}/man/man1/foo.1.gz
|
|
${MANPREFIX}/man/de/man1/foo.1.gz
|
|
${MANPREFIX}/man/ja/man1/foo.1.gz
|
|
${MANPREFIX}/man/man1/bar.1.gz
|
|
${MANPREFIX}/man/de/man3/baz.3.gz</programlisting>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-info">
|
|
<title>Info Files</title>
|
|
|
|
<para>If your package needs to install GNU info files, they
|
|
should be listed in the <makevar>INFO</makevar> variable
|
|
(without the trailing <literal>.info</literal>), one entry per
|
|
document. These files are assumed to be installed to
|
|
<filename><makevar>PREFIX</makevar>/<makevar>INFO_PATH</makevar></filename>.
|
|
You can change <makevar>INFO_PATH</makevar> if your package
|
|
uses a different location. However, this is not recommended.
|
|
These entries contain just the path relative to
|
|
<filename><makevar>PREFIX</makevar>/<makevar>INFO_PATH</makevar></filename>.
|
|
For example, <filename role="package">lang/gcc34</filename>
|
|
installs info files to
|
|
<filename><makevar>PREFIX</makevar>/<makevar>INFO_PATH</makevar>/gcc34</filename>,
|
|
and <makevar>INFO</makevar> will be something like
|
|
this:</para>
|
|
|
|
<programlisting>INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ...</programlisting>
|
|
|
|
<para>Appropriate installation/de-installation code will be
|
|
automatically added to the temporary
|
|
<filename>pkg-plist</filename> before package
|
|
registration.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-options">
|
|
<title>Makefile Options</title>
|
|
|
|
<para>Many applications can be built with optional or differing
|
|
configurations. Examples include choice of natural (human)
|
|
language, GUI versus command-line, or type of database to
|
|
support. Users may need a different configuration than the
|
|
default, so the ports system provides hooks the port author
|
|
can use to control which variant will be built. Supporting
|
|
these options properly will make users happy, and effectively
|
|
provide two or more ports for the price of one.</para>
|
|
|
|
<sect2>
|
|
<title>Knobs</title>
|
|
|
|
<sect3>
|
|
<title><makevar>WITH_<replaceable>*</replaceable></makevar>
|
|
and
|
|
<makevar>WITHOUT_<replaceable>*</replaceable></makevar></title>
|
|
|
|
<para>These variables are designed to be set by the system
|
|
administrator. There are many that are standardized in
|
|
the <ulink
|
|
url="http://svn.FreeBSD.org/ports/head/KNOBS?view=markup"><filename>ports/KNOBS</filename></ulink>
|
|
file.</para>
|
|
|
|
<para>When creating a port, do not make knob names specific
|
|
to a given application. For example in Avahi port, use
|
|
<makevar>WITHOUT_MDNS</makevar> instead of
|
|
<makevar>WITHOUT_AVAHI_MDNS</makevar>.</para>
|
|
|
|
<note>
|
|
<para>You should not assume that a
|
|
<makevar>WITH_<replaceable>*</replaceable></makevar>
|
|
necessarily has a corresponding
|
|
<makevar>WITHOUT_<replaceable>*</replaceable></makevar>
|
|
variable and vice versa. In general, the default is
|
|
simply assumed.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>Unless otherwise specified, these variables are only
|
|
tested for being set or not set, rather than being set
|
|
to a specific value such as <literal>YES</literal>
|
|
or <literal>NO</literal>.</para>
|
|
</note>
|
|
|
|
<table frame="none">
|
|
<title>Common
|
|
<makevar>WITH_<replaceable>*</replaceable></makevar> and
|
|
<makevar>WITHOUT_<replaceable>*</replaceable></makevar>
|
|
Variables</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Means</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row id="knobs-without-nls">
|
|
<entry><makevar>WITHOUT_NLS</makevar></entry>
|
|
<entry>If set, says that internationalization is not
|
|
needed, which can save compile time. By default,
|
|
internationalization is used.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_OPENSSL_BASE</makevar></entry>
|
|
<entry>Use the version of OpenSSL in the base
|
|
system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_OPENSSL_PORT</makevar></entry>
|
|
<entry>Installs the version of OpenSSL from
|
|
<filename
|
|
role="package">security/openssl</filename>, even
|
|
if the base is up to date.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITHOUT_X11</makevar></entry>
|
|
<entry>Ports that can be built both with and
|
|
without X support are normally
|
|
built with X support. If this variable is
|
|
defined, then the version that does not have X
|
|
support will be built instead.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Knob Naming</title>
|
|
|
|
<para>Porters should use like-named knobs, both
|
|
for the benefit of end-users and to help keep the number
|
|
of knob names down. A list of popular knob names can be
|
|
found in the <ulink
|
|
url="http://svn.FreeBSD.org/ports/head/KNOBS?view=markup"><filename>KNOBS</filename></ulink>
|
|
file.</para>
|
|
|
|
<para>Knob names should reflect what the knob is and does.
|
|
When a port has a lib-prefix in the
|
|
<makevar>PORTNAME</makevar> the lib-prefix should be
|
|
dropped in knob naming.</para>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>OPTIONS</makevar></title>
|
|
|
|
<sect3>
|
|
<title>Background</title>
|
|
|
|
<para>The <makevar>OPTIONS_*</makevar> variables give the
|
|
user installing the port a dialog showing the available
|
|
options, and then saves those options to
|
|
<filename>/var/db/ports/<makevar>${UNIQUENAME}</makevar>/options</filename>.
|
|
The next time the port is built, the options are
|
|
reused.</para>
|
|
|
|
<para>When the user runs <command>make config</command> (or
|
|
runs <command>make build</command> for the first time),
|
|
the framework checks for
|
|
<filename>/var/db/ports/<makevar>${UNIQUENAME}</makevar>/options</filename>.
|
|
If that file does not exist, the values of
|
|
<makevar>OPTIONS_*</makevar> are used, and a dialog box is
|
|
displayed where the options can be enabled or disabled.
|
|
Then the <filename>options</filename> file is saved and
|
|
the configured variables are used when building the
|
|
port.</para>
|
|
|
|
<para>If a new version of the port adds new
|
|
<makevar>OPTIONS</makevar>, the dialog will be presented
|
|
to the user with the saved values of old
|
|
<makevar>OPTIONS</makevar> prefilled.</para>
|
|
|
|
<para><command>make showconfig</command> shows the
|
|
saved configuration. Use <command>make rmconfig</command>
|
|
to remove the saved configuration.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Syntax</title>
|
|
|
|
<para><makevar>OPTIONS_DEFINE</makevar> contains a list of
|
|
<makevar>OPTIONS</makevar> to be used. These are
|
|
independent of each other and are not grouped:</para>
|
|
|
|
<programlisting>OPTIONS_DEFINE= OPT1 OPT2</programlisting>
|
|
|
|
<para>Once defined, <makevar>OPTIONS</makevar> are
|
|
described (optional, but strongly recommended):</para>
|
|
|
|
<programlisting>OPT1_DESC= Describe OPT1
|
|
OPT2_DESC= Describe OPT2
|
|
OPT3_DESC= Describe OPT3
|
|
OPT4_DESC= Describe OPT4
|
|
OPT5_DESC= Describe OPT5
|
|
OPT6_DESC= Describe OPT6</programlisting>
|
|
|
|
<tip>
|
|
<para><filename>ports/Mk/bsd.options.desc.mk</filename>
|
|
has descriptions for many common
|
|
<makevar>OPTIONS</makevar>; there is usually no need
|
|
to override these.</para>
|
|
</tip>
|
|
|
|
<tip>
|
|
<para>When describing options, view it from the
|
|
perspective of the user: <quote>What does it do?</quote>
|
|
and <quote>Why would I want to enable this?</quote> Do
|
|
not just repeat the name. For example, describing the
|
|
<literal>NLS</literal> option as
|
|
<quote>include NLS support</quote> does not help the
|
|
user, who can already see the option name but may not
|
|
know what it means. Describing it as <quote>Native
|
|
Language Support via gettext utilities</quote> is
|
|
much more helpful.</para>
|
|
</tip>
|
|
|
|
<para><makevar>OPTIONS</makevar> can be grouped as radio
|
|
choices, where only one choice from each group is
|
|
allowed:</para>
|
|
|
|
<programlisting>OPTIONS_SINGLE= SG1
|
|
OPTIONS_SINGLE_SG1= OPT3 OPT4</programlisting>
|
|
|
|
<para><makevar>OPTIONS</makevar> can also be grouped as
|
|
<quote>multiple-choice</quote> lists, where
|
|
<emphasis>at least one</emphasis> option must be
|
|
enabled:</para>
|
|
|
|
<programlisting>OPTIONS_MULTI= MG1
|
|
OPTIONS_MULTI_MG1= OPT5 OPT6</programlisting>
|
|
|
|
<para><makevar>OPTIONS_MULTI</makevar> and
|
|
<makevar>OPTIONS_SINGLE</makevar> can also allow zero
|
|
choices by including the group in
|
|
<makevar>OPTIONS_DEFINE</makevar>:</para>
|
|
|
|
<programlisting>OPTIONS_DEFINE= MG1
|
|
OPTIONS_MULTI= MG1
|
|
OPTIONS_MULTI_MG1= OPT5 OPT6</programlisting>
|
|
|
|
<para>This group then requires at least one
|
|
<makevar>OPTION</makevar> from <makevar>MG1</makevar>
|
|
only if the new <makevar>MG1</makevar>
|
|
<makevar>OPTION</makevar> is selected. Experimentation
|
|
is encouraged to ensure that this is understood.</para>
|
|
|
|
<para><makevar>OPTIONS</makevar> are unset by default,
|
|
unless they are listed in
|
|
<makevar>OPTIONS_DEFAULT</makevar>:</para>
|
|
|
|
<programlisting>OPTIONS_DEFAULT= OPT1 OPT3 OPT6</programlisting>
|
|
|
|
<para><makevar>OPTIONS</makevar> definitions must appear
|
|
before the inclusion of
|
|
<filename>bsd.port.options.mk</filename>. The
|
|
<makevar>PORT_OPTIONS</makevar> variable can only be
|
|
tested after the inclusion of
|
|
<filename>bsd.port.options.mk</filename>. Inclusion of
|
|
<filename>bsd.port.pre.mk</filename> can be used instead,
|
|
too, and is still widely used in ports written before the
|
|
introduction of <filename>bsd.port.options.mk</filename>.
|
|
But be aware that some variables will not work as expected
|
|
after the inclusion of
|
|
<filename>bsd.port.pre.mk</filename>, typically some
|
|
<makevar>USE_*</makevar> flags.</para>
|
|
|
|
<example id="ports-options-simple-use">
|
|
<title>Simple Use of <makevar>OPTIONS</makevar></title>
|
|
|
|
<programlisting>OPTIONS_DEFINE= FOO BAR
|
|
FOO_DESC= Enable option foo
|
|
BAR_DESC= Support feature bar
|
|
|
|
OPTIONS_DEFAULT=FOO
|
|
|
|
.include <bsd.port.options.mk>
|
|
|
|
.if ${PORT_OPTIONS:MFOO}
|
|
CONFIGURE_ARGS+=--with-foo
|
|
.else
|
|
CONFIGURE_ARGS+=--without-foo
|
|
.endif
|
|
|
|
.if ${PORT_OPTIONS:MBAR}
|
|
RUN_DEPENDS+= bar:${PORTSDIR}/bar/bar
|
|
.endif
|
|
|
|
.include <bsd.port.mk></programlisting>
|
|
</example>
|
|
|
|
<example id="ports-options-practical-use">
|
|
<title>Practical Use of <makevar>OPTIONS</makevar></title>
|
|
|
|
<programlisting>OPTIONS_DEFINE= EXAMPLES
|
|
|
|
OPTIONS_SINGLE= BACKEND
|
|
OPTIONS_SINGLE_BACKEND= MYSQL PGSQL BDB
|
|
|
|
OPTIONS_MULTI= AUTH
|
|
OPTIONS_MULTI_AUTH= LDAP PAM SSL
|
|
|
|
EXAMPLES_DESC= Install extra examples
|
|
MYSQL_DESC= Use MySQL as backend
|
|
PGSQL_DESC= Use PostgreSQL as backend
|
|
BDB_DESC= Use Berkeley DB as backend
|
|
LDAP_DESC= Build with LDAP authentication support
|
|
PAM_DESC= Build with PAM support
|
|
SSL_DESC= Build with OpenSSL support
|
|
|
|
OPTIONS_DEFAULT= PGSQL LDAP SSL
|
|
|
|
.include <bsd.port.options.mk>
|
|
|
|
.if ${PORT_OPTIONS:MPGSQL}
|
|
USE_PGSQL= yes
|
|
CONFIGURE_ARGS+= --with-postgres
|
|
.else
|
|
CONFIGURE_ARGS+= --without-postgres
|
|
.endif
|
|
|
|
.if ${PORT_OPTIONS:MICU}
|
|
LIB_DEPENDS+= icuuc:${PORTSDIR}/devel/icu
|
|
.endif
|
|
|
|
# Check other OPTIONS
|
|
|
|
.include <bsd.port.mk></programlisting>
|
|
</example>
|
|
|
|
<example id="ports-options-old-style-use">
|
|
<title>Old-Style Use of <makevar>OPTIONS</makevar></title>
|
|
|
|
<programlisting>OPTIONS= FOO "Enable option foo" On
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if defined(WITHOUT_FOO)
|
|
CONFIGURE_ARGS+= --without-foo
|
|
.else
|
|
CONFIGURE_ARGS+= --with-foo
|
|
.endif
|
|
|
|
.include <bsd.port.post.mk></programlisting>
|
|
</example>
|
|
|
|
<important>
|
|
<para>This method of using <makevar>OPTIONS</makevar>
|
|
is deprecated, and will be removed at some point.
|
|
Do not use this method for new ports.</para>
|
|
</important>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Feature Auto-Activation</title>
|
|
|
|
<para>When using a GNU configure script, keep an eye on which
|
|
optional features are activated by auto-detection.
|
|
Explicitly disable optional features you do not wish to be
|
|
used by passing respective <literal>--without-xxx</literal>
|
|
or <literal>--disable-xxx</literal> in
|
|
<makevar>CONFIGURE_ARGS</makevar>.</para>
|
|
|
|
<example>
|
|
<title>Wrong Handling of an Option</title>
|
|
|
|
<programlisting>.if ${PORT_OPTIONS:MFOO}
|
|
LIB_DEPENDS+= foo:${PORTSDIR}/devel/foo
|
|
CONFIGURE_ARGS+= --enable-foo
|
|
.endif</programlisting>
|
|
</example>
|
|
|
|
<para>In the example above, imagine a library libfoo is
|
|
installed on the system. The user does not want this
|
|
application to use libfoo, so he toggled the option off in
|
|
the <literal>make config</literal> dialog. But the
|
|
application's configure script detects the library present
|
|
in the system and includes its support in the resulting
|
|
executable. Now when the user decides to remove libfoo from the
|
|
system, the ports system does not protest (no dependency on
|
|
libfoo was recorded) but the application breaks.</para>
|
|
|
|
<example>
|
|
<title>Correct Handling of an Option</title>
|
|
|
|
<programlisting>.if ${PORT_OPTIONS:MFOO}
|
|
LIB_DEPENDS+= foo:${PORTSDIR}/devel/foo
|
|
CONFIGURE_ARGS+= --enable-foo
|
|
.else
|
|
CONFIGURE_ARGS+= --disable-foo
|
|
.endif</programlisting>
|
|
</example>
|
|
|
|
<para>In the second example, the library libfoo is explicitly
|
|
disabled. The configure script does not enable related
|
|
features in the application, despite library's presence in
|
|
the system.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="makefile-wrkdir">
|
|
<title>Specifying the Working Directory</title>
|
|
|
|
<para>Each port is extracted in to a working directory, which
|
|
must be writable. The ports system defaults to having the
|
|
<makevar>DISTFILES</makevar> unpack in to a directory called
|
|
<literal>${DISTNAME}</literal>. In other words, if you have
|
|
set:</para>
|
|
|
|
<programlisting>PORTNAME= foo
|
|
PORTVERSION= 1.0</programlisting>
|
|
|
|
<para>then the port's distribution files contain a top-level
|
|
directory, <filename>foo-1.0</filename>, and the rest of the
|
|
files are located under that directory.</para>
|
|
|
|
<para>There are a number of variables you can override if that
|
|
is not the case.</para>
|
|
|
|
<sect2>
|
|
<title><makevar>WRKSRC</makevar></title>
|
|
|
|
<para>The variable lists the name of the directory that is
|
|
created when the application's distfiles are extracted. If
|
|
our previous example extracted into a directory called
|
|
<filename>foo</filename> (and not
|
|
<filename>foo-1.0</filename>) you would write:</para>
|
|
|
|
<programlisting>WRKSRC= ${WRKDIR}/foo</programlisting>
|
|
|
|
<para>or possibly</para>
|
|
|
|
<programlisting>WRKSRC= ${WRKDIR}/${PORTNAME}</programlisting>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>NO_WRKSUBDIR</makevar></title>
|
|
|
|
<para>If the port does not extract in to a subdirectory at all
|
|
then you should set <makevar>NO_WRKSUBDIR</makevar> to
|
|
indicate that.</para>
|
|
|
|
<programlisting>NO_WRKSUBDIR= yes</programlisting>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="conflicts">
|
|
<title>Conflict Handling</title>
|
|
|
|
<para>There are three different variables to register a conflict
|
|
between packages and ports: <makevar>CONFLICTS</makevar>,
|
|
<makevar>CONFLICTS_INSTALL</makevar> and
|
|
<makevar>CONFLICTS_BUILD</makevar>.</para>
|
|
|
|
<note>
|
|
<para>The conflict variables automatically set the variable
|
|
<makevar>IGNORE</makevar>, which is more fully documented
|
|
in <xref linkend="dads-noinstall"/>.</para>
|
|
</note>
|
|
|
|
<para>When removing one of several conflicting ports, it is
|
|
advisable to retain the <makevar>CONFLICTS</makevar> entries
|
|
in those other ports for a few months to cater for users who
|
|
only update once in a while.</para>
|
|
|
|
<sect2>
|
|
<title><makevar>CONFLICTS_INSTALL</makevar></title>
|
|
|
|
<para>If your package cannot coexist with other packages
|
|
(because of file conflicts, runtime incompatibilities,
|
|
etc.), list the other package names in the
|
|
<makevar>CONFLICTS_INSTALL</makevar> variable. You can use
|
|
shell globs like <literal>*</literal> and
|
|
<literal>?</literal> here. Package names should be
|
|
enumerated the same way they appear in
|
|
<filename>/var/db/pkg</filename>. Please make sure that
|
|
<makevar>CONFLICTS_INSTALL</makevar> does not match this
|
|
port's package itself. Otherwise enforcing its installation
|
|
with <makevar>FORCE_PKG_REGISTER</makevar> will no longer
|
|
work. The CONFLICTS_INSTALL check is done after the build
|
|
stage and prior to the install stage.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>CONFLICTS_BUILD</makevar></title>
|
|
|
|
<para>If your port cannot be built if a certain port is
|
|
already installed, list the other port names in the
|
|
<makevar>CONFLICTS_BUILD</makevar> variable. You can use
|
|
shell globs like <literal>*</literal> and
|
|
<literal>?</literal> here. Package names should be
|
|
enumerated the same way they appear in
|
|
<filename>/var/db/pkg</filename>. The CONFLICTS_BUILD check
|
|
is done prior to the build stage. Build conflicts are not
|
|
recorded in the resulting package.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>CONFLICTS</makevar></title>
|
|
|
|
<para>If your port cannot be built if a certain port is
|
|
already installed and the resulting package cannot coexist
|
|
with the other package, list the other package name in the
|
|
<makevar>CONFLICTS</makevar> variable. You can use shell
|
|
globs like <literal>*</literal> and <literal>?</literal>
|
|
here. Packages names should be enumerated the same way they
|
|
appear in <filename>/var/db/pkg</filename>. Please make
|
|
sure that <makevar>CONFLICTS_INSTALL</makevar> does not
|
|
match this port's package itself. Otherwise enforcing its
|
|
installation with <makevar>FORCE_PKG_REGISTER</makevar> will
|
|
no longer work. The CONFLICTS check is done prior to the
|
|
build stage and prior to the install stage.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="install">
|
|
<title>Installing Files</title>
|
|
|
|
<sect2 id="install-macros">
|
|
<title><makevar>INSTALL_*</makevar> Macros</title>
|
|
|
|
<para>Do use the macros provided in
|
|
<filename>bsd.port.mk</filename> to ensure correct modes and
|
|
ownership of files in your own
|
|
<maketarget>*-install</maketarget> targets.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para><makevar>INSTALL_PROGRAM</makevar> is a command to
|
|
install binary executables.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>INSTALL_SCRIPT</makevar> is a command to
|
|
install executable scripts.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>INSTALL_LIB</makevar> is a command to
|
|
install shared libraries.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>INSTALL_KLD</makevar> is a command to
|
|
install kernel loadable modules. Some architectures
|
|
do not like having the modules stripped, so
|
|
use this command instead of
|
|
<makevar>INSTALL_PROGRAM</makevar>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>INSTALL_DATA</makevar> is a command to
|
|
install sharable data.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>INSTALL_MAN</makevar> is a command to
|
|
install manpages and other documentation (it does not
|
|
compress anything).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>These are basically the <command>install</command>
|
|
command with all the appropriate flags.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="install-strip">
|
|
<title>Stripping Binaries and Shared Libraries</title>
|
|
|
|
<para>Do not strip binaries manually unless you have to. All
|
|
binaries should be stripped, but the
|
|
<makevar>INSTALL_PROGRAM</makevar> macro will install and
|
|
strip a binary at the same time (see the next section). The
|
|
<makevar>INSTALL_LIB</makevar> macro does the same thing to
|
|
shared libraries.</para>
|
|
|
|
<para>If you need to strip a file, but wish to use neither
|
|
<makevar>INSTALL_PROGRAM</makevar> nor
|
|
<makevar>INSTALL_LIB</makevar> macros,
|
|
<makevar>${STRIP_CMD}</makevar> will strip your program or
|
|
shared library. This is typically done within the
|
|
<maketarget>post-install</maketarget> target. For
|
|
example:</para>
|
|
|
|
<programlisting>post-install:
|
|
${STRIP_CMD} ${PREFIX}/bin/xdl</programlisting>
|
|
|
|
<para>Use the &man.file.1; command on the installed executable
|
|
to check whether the binary is stripped or not. If it does
|
|
not say <literal>not stripped</literal>, it is stripped.
|
|
Additionally, &man.strip.1; will not strip a previously
|
|
stripped program; it will instead exit cleanly.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="install-copytree">
|
|
<title>Installing a Whole Tree of Files</title>
|
|
|
|
<para>Sometimes, there is a need to install a big number of
|
|
files, preserving their hierarchical organization, i.e.,
|
|
copying over a whole directory tree from
|
|
<makevar>WRKSRC</makevar> to a target directory under
|
|
<makevar>PREFIX</makevar>.</para>
|
|
|
|
<para>Two macros exist for this situation. The advantage of
|
|
using these macros instead of <command>cp</command> is that
|
|
they guarantee proper file ownership and permissions on
|
|
target files. The first macro,
|
|
<makevar>COPYTREE_BIN</makevar>, will set all the installed
|
|
files to be executable, thus being suitable for installing
|
|
into <filename><makevar>PREFIX</makevar>/bin</filename>.
|
|
The second macro, <makevar>COPYTREE_SHARE</makevar>, does
|
|
not set executable permissions on files, and is therefore
|
|
suitable for installing files under
|
|
<filename><makevar>PREFIX</makevar>/share</filename>
|
|
target.</para>
|
|
|
|
<programlisting>post-install:
|
|
${MKDIR} ${EXAMPLESDIR}
|
|
(cd ${WRKSRC}/examples/ && ${COPYTREE_SHARE} \* ${EXAMPLESDIR})</programlisting>
|
|
|
|
<para>This example will install the contents of
|
|
<filename>examples</filename> directory in the vendor
|
|
distfile to the proper examples location of your
|
|
port.</para>
|
|
|
|
<programlisting>post-install:
|
|
${MKDIR} ${DATADIR}/summer
|
|
(cd ${WRKSRC}/temperatures/ && ${COPYTREE_SHARE} "June July August" ${DATADIR}/summer/)</programlisting>
|
|
|
|
<para>And this example will install the data of summer months
|
|
to the <filename>summer</filename> subdirectory of a
|
|
<filename><makevar>DATADIR</makevar></filename>.</para>
|
|
|
|
<para>Additional <command>find</command> arguments can be
|
|
passed via the third argument to the
|
|
<makevar>COPYTREE_*</makevar> macros. For example, to
|
|
install all files from the first example except Makefiles,
|
|
one can use the following command.</para>
|
|
|
|
<programlisting>post-install:
|
|
${MKDIR} ${EXAMPLESDIR}
|
|
(cd ${WRKSRC}/examples/ && \
|
|
${COPYTREE_SHARE} \* ${EXAMPLESDIR} "! -name Makefile")</programlisting>
|
|
|
|
<para>Note that these macros does not add the installed files
|
|
to <filename>pkg-plist</filename>. You still need to list
|
|
them.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="install-documentation">
|
|
<title>Install Additional Documentation</title>
|
|
|
|
<para>If your software has some documentation other than the
|
|
standard man and info pages that you think is useful for the
|
|
user, install it under
|
|
<filename><makevar>PREFIX</makevar>/share/doc</filename>.
|
|
This can be done, like the previous item, in the
|
|
<maketarget>post-install</maketarget> target.</para>
|
|
|
|
<para>Create a new directory for your port. The directory
|
|
name should reflect what the port is. This usually means
|
|
<makevar>PORTNAME</makevar>. However, if you think the user
|
|
might want different versions of the port to be installed at
|
|
the same time, you can use the whole
|
|
<makevar>PKGNAME</makevar>.</para>
|
|
|
|
<para>Make the installation dependent on the variable
|
|
<makevar>NOPORTDOCS</makevar> so that users can disable it
|
|
in <filename>/etc/make.conf</filename>, like this:</para>
|
|
|
|
<programlisting>post-install:
|
|
.if !defined(NOPORTDOCS)
|
|
${MKDIR} ${DOCSDIR}
|
|
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
|
|
.endif</programlisting>
|
|
|
|
<para>Here are some handy variables and how they are expanded
|
|
by default when usedin the
|
|
<filename>Makefile</filename>:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>DATADIR</makevar> gets expanded to
|
|
<filename><makevar>PREFIX</makevar>/share/<makevar>PORTNAME</makevar></filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>DATADIR_REL</makevar> gets expanded to
|
|
<filename>share/<makevar>PORTNAME</makevar></filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>DOCSDIR</makevar> gets expanded to
|
|
<filename><makevar>PREFIX</makevar>/share/doc/<makevar>PORTNAME</makevar></filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>DOCSDIR_REL</makevar> gets expanded to
|
|
<filename>share/doc/<makevar>PORTNAME</makevar></filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>EXAMPLESDIR</makevar> gets expanded to
|
|
<filename><makevar>PREFIX</makevar>/share/examples/<makevar>PORTNAME</makevar></filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>EXAMPLESDIR_REL</makevar> gets expanded to
|
|
<filename>share/examples/<makevar>PORTNAME</makevar></filename>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para><makevar>NOPORTDOCS</makevar> only controls additional
|
|
documentation installed in <makevar>DOCSDIR</makevar>. It
|
|
does not apply to standard man pages and info pages.
|
|
Things installed in <makevar>DATADIR</makevar> and
|
|
<makevar>EXAMPLESDIR</makevar> are controlled by
|
|
<makevar>NOPORTDATA</makevar> and
|
|
<makevar>NOPORTEXAMPLES</makevar>, respectively.</para>
|
|
</note>
|
|
|
|
<para>These variables are exported to
|
|
<makevar>PLIST_SUB</makevar>. Their values will appear
|
|
there as pathnames relative to
|
|
<filename><makevar>PREFIX</makevar></filename> if possible.
|
|
That is,
|
|
<filename>share/doc/<makevar>PORTNAME</makevar></filename>
|
|
will be substituted for <literal>%%DOCSDIR%%</literal> in
|
|
the packing list by default, and so on. (See more on
|
|
<filename>pkg-plist</filename> substitution <link
|
|
linkend="plist-sub">here</link>.)</para>
|
|
|
|
<para>All conditionally installed documentation files and
|
|
directories should be included in
|
|
<filename>pkg-plist</filename> with the
|
|
<literal>%%PORTDOCS%%</literal> prefix, for example:</para>
|
|
|
|
<programlisting>%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
|
|
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
|
|
%%PORTDOCS%%@dirrm %%DOCSDIR%%</programlisting>
|
|
|
|
<para>As an alternative to enumerating the documentation files
|
|
in <filename>pkg-plist</filename>, a port can set the
|
|
variable <makevar>PORTDOCS</makevar> to a list of file names
|
|
and shell glob patterns to add to the final packing list.
|
|
The names will be relative to <makevar>DOCSDIR</makevar>.
|
|
Therefore, a port that utilizes <makevar>PORTDOCS</makevar>
|
|
and uses a non-default location for its documentation should
|
|
set <makevar>DOCSDIR</makevar> accordingly. If a directory
|
|
is listed in <makevar>PORTDOCS</makevar> or matched by a
|
|
glob pattern from this variable, the entire subtree of
|
|
contained files and directories will be registered in the
|
|
final packing list. If <makevar>NOPORTDOCS</makevar> is
|
|
defined then files and directories listed in
|
|
<makevar>PORTDOCS</makevar> would not be installed and
|
|
neither would be added to port packing list. Installing the
|
|
documentation at <makevar>PORTDOCS</makevar> as shown above
|
|
remains up to the port itself. A typical example of
|
|
utilizing <makevar>PORTDOCS</makevar> looks as
|
|
follows:</para>
|
|
|
|
<programlisting>PORTDOCS= README.* ChangeLog docs/*</programlisting>
|
|
|
|
<note>
|
|
<para>The equivalents of <makevar>PORTDOCS</makevar> for
|
|
files installed under <makevar>DATADIR</makevar> and
|
|
<makevar>EXAMPLESDIR</makevar> are
|
|
<makevar>PORTDATA</makevar> and
|
|
<makevar>PORTEXAMPLES</makevar>, respectively.</para>
|
|
|
|
<para>You can also use the <filename>pkg-message</filename>
|
|
file to display messages upon installation. See <link
|
|
linkend="porting-message">the section on using
|
|
<filename>pkg-message</filename></link> for details. The
|
|
<filename>pkg-message</filename> file does not need to be
|
|
added to <filename>pkg-plist</filename>.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 id="install-subdirs">
|
|
<title>Subdirectories Under <makevar>PREFIX</makevar></title>
|
|
|
|
<para>Try to let the port put things in the right
|
|
subdirectories of <makevar>PREFIX</makevar>. Some ports
|
|
lump everything and put it in the subdirectory with the
|
|
port's name, which is incorrect. Also, many ports put
|
|
everything except binaries, header files and manual pages in
|
|
a subdirectory of <filename>lib</filename>, which does not
|
|
work well with the BSD paradigm. Many of the files should
|
|
be moved to one of the following: <filename>etc</filename>
|
|
(setup/configuration files), <filename>libexec</filename>
|
|
(executables started internally), <filename>sbin</filename>
|
|
(executables for superusers/managers),
|
|
<filename>info</filename> (documentation for info browser)
|
|
or <filename>share</filename> (architecture independent
|
|
files). See &man.hier.7; for details; the rules governing
|
|
<filename>/usr</filename> pretty much apply to
|
|
<filename>/usr/local</filename> too. The exception are
|
|
ports dealing with USENET <quote>news</quote>. They may use
|
|
<filename><makevar>PREFIX</makevar>/news</filename> as a
|
|
destination for their files.</para>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="special">
|
|
<title>Special Considerations</title>
|
|
|
|
<para>There are some more things you have to take into account
|
|
when you create a port. This section explains the most common
|
|
of those.</para>
|
|
|
|
<sect1 id="porting-shlibs">
|
|
<title>Shared Libraries</title>
|
|
|
|
<para>If your port installs one or more shared libraries, define
|
|
a <makevar>USE_LDCONFIG</makevar> make variable, which will
|
|
instruct a <filename>bsd.port.mk</filename> to run
|
|
<literal>${LDCONFIG} -m</literal> on the directory
|
|
where the new library is installed (usually
|
|
<filename><makevar>PREFIX</makevar>/lib</filename>) during
|
|
<maketarget>post-install</maketarget> target to register it
|
|
into the shared library cache. This variable, when defined,
|
|
will also facilitate addition of an appropriate
|
|
<literal>@exec /sbin/ldconfig -m</literal> and
|
|
<literal>@unexec /sbin/ldconfig -R</literal> pair into your
|
|
<filename>pkg-plist</filename> 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.</para>
|
|
|
|
<programlisting>USE_LDCONFIG= yes</programlisting>
|
|
|
|
<para>If you need, you can override the default directory by
|
|
setting the <makevar>USE_LDCONFIG</makevar> value to a list of
|
|
directories into which shared libraries are to be installed.
|
|
For example if your port installs shared libraries into
|
|
<filename><makevar>PREFIX</makevar>/lib/foo</filename> and
|
|
<filename><makevar>PREFIX</makevar>/lib/bar</filename>
|
|
directories you could use the following in your
|
|
<filename>Makefile</filename>:</para>
|
|
|
|
<programlisting>USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar</programlisting>
|
|
|
|
<para>Please double-check, often this is not necessary at all or
|
|
can be avoided through <literal>-rpath</literal> or setting
|
|
<envar>LD_RUN_PATH</envar> during linking (see <filename
|
|
role="package">lang/moscow_ml</filename> for an example), or
|
|
through a shell-wrapper which sets
|
|
<makevar>LD_LIBRARY_PATH</makevar> before invoking the binary,
|
|
like <filename role="package">www/seamonkey</filename>
|
|
does.</para>
|
|
|
|
<para>When installing 32-bit libraries on 64-bit system, use
|
|
<makevar>USE_LDCONFIG32</makevar> instead.</para>
|
|
|
|
<para>Try to keep shared library version numbers in the
|
|
<filename>libfoo.so.0</filename> format. Our runtime linker
|
|
only cares for the major (first) number.</para>
|
|
|
|
<para>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
|
|
<makevar>PORTREVISION</makevar> incremented, to force
|
|
recompilation with the new library version.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-restrictions">
|
|
<title>Ports with Distribution Restrictions</title>
|
|
|
|
<para>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.</para>
|
|
|
|
<important>
|
|
<para>It is your responsibility as a porter to read the
|
|
licensing terms of the software and make sure that the
|
|
FreeBSD 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;.</para>
|
|
</important>
|
|
|
|
<para>In situations like this, the variables described in the
|
|
following sections can be set.</para>
|
|
|
|
<sect2>
|
|
<title><makevar>NO_PACKAGE</makevar></title>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>However, the port's <makevar>DISTFILES</makevar> may be
|
|
freely mirrored on FTP/HTTP. They may also be distributed
|
|
on a CD-ROM (or similar media) unless
|
|
<makevar>NO_CDROM</makevar> is set as well.</para>
|
|
|
|
<para><makevar>NO_PACKAGE</makevar> 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 <makevar>NO_PACKAGE</makevar>.</para>
|
|
|
|
<para><makevar>NO_PACKAGE</makevar> should be set to a string
|
|
describing the reason why the package should not be
|
|
generated.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>NO_CDROM</makevar></title>
|
|
|
|
<para>This variable alone indicates that, although we are
|
|
allowed to generate binary packages, we may put neither
|
|
those packages nor the port's <makevar>DISTFILES</makevar>
|
|
onto a CD-ROM (or similar media) for resale. However, the
|
|
binary packages and the port's <makevar>DISTFILES</makevar>
|
|
will still be available via FTP/HTTP.</para>
|
|
|
|
<para> If this variable is set along with
|
|
<makevar>NO_PACKAGE</makevar>, then only the port's
|
|
<makevar>DISTFILES</makevar> will be available, and only via
|
|
FTP/HTTP.</para>
|
|
|
|
<para><makevar>NO_CDROM</makevar> 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 <quote>non-commercial</quote> use
|
|
only.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>NOFETCHFILES</makevar></title>
|
|
|
|
<para>Files defined in the <makevar>NOFETCHFILES</makevar>
|
|
variable are not fetchable from any of the
|
|
<makevar>MASTER_SITES</makevar>. An example of such a file
|
|
is when the file is supplied on CD-ROM by the vendor.</para>
|
|
|
|
<para>Tools which check for the availability of these files
|
|
on the <makevar>MASTER_SITES</makevar> should ignore these
|
|
files and not report about them.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>RESTRICTED</makevar></title>
|
|
|
|
<para>Set this variable alone if the application's license
|
|
permits neither mirroring the application's
|
|
<makevar>DISTFILES</makevar> nor distributing the binary
|
|
package in any way.</para>
|
|
|
|
<para><makevar>NO_CDROM</makevar> or
|
|
<makevar>NO_PACKAGE</makevar> should not be set along with
|
|
<makevar>RESTRICTED</makevar> since the latter variable
|
|
implies the former ones.</para>
|
|
|
|
<para><makevar>RESTRICTED</makevar> 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 <makevar>DISTFILES</makevar>, possibly after registering
|
|
for the software or agreeing to accept the terms of an
|
|
<acronym>EULA</acronym>.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title><makevar>RESTRICTED_FILES</makevar></title>
|
|
|
|
<para>When <makevar>RESTRICTED</makevar> or
|
|
<makevar>NO_CDROM</makevar> is set, this variable defaults
|
|
to <literal>${DISTFILES} ${PATCHFILES}</literal>, otherwise
|
|
it is empty. If only some of the distribution files are
|
|
restricted, then set this variable to list them.</para>
|
|
|
|
<para>Note that the port committer should add an entry to
|
|
<filename>/usr/ports/LEGAL</filename> for every listed
|
|
distribution file, describing exactly what the restriction
|
|
entails.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Examples</title>
|
|
|
|
<para>The preferred way to state "the distfiles for this port
|
|
must be fetched manually" is as follows:</para>
|
|
|
|
<programlisting>.if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX})
|
|
IGNORE= may not be redistributed because of licensing reasons. Please visit <replaceable>some-website</replaceable> to accept their license and download ${DISTFILES} into ${DISTDIR}
|
|
.endif</programlisting>
|
|
|
|
<para>This both informs the user, and sets the proper metadata
|
|
on the user's machine for use by automated programs.</para>
|
|
|
|
<para>Note that this stanza must be preceded by an inclusion
|
|
of <filename>bsd.port.pre.mk</filename>.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="building">
|
|
<title>Building Mechanisms</title>
|
|
|
|
<sect2 id="parallel-builds">
|
|
<title>Building Ports in Parallel</title>
|
|
|
|
<para>The &os; ports framework supports parallel building
|
|
using multiple <command>make</command> sub-processes, which
|
|
allows <acronym>SMP</acronym> systems to utilize all of
|
|
their available <acronym>CPU</acronym> power, allowing port
|
|
builds to be faster and more effective.</para>
|
|
|
|
<para>This is achieved by passing <makevar>-jX</makevar> flag
|
|
to &man.make.1; running on vendor code. Unfortunately, not
|
|
all ports handle parallel building well. Therefore it is
|
|
required to explicitly enable this feature by adding
|
|
<literal>MAKE_JOBS_SAFE=yes</literal> somewhere below the
|
|
dependency declaration section of the
|
|
<filename>Makefile</filename>.</para>
|
|
|
|
<para>Another option for controlling this feature from the
|
|
maintainer's point of view is the
|
|
<makevar>MAKE_JOBS_UNSAFE=yes</makevar> variable. It is
|
|
used when a port is known to be broken with
|
|
<makevar>-jX</makevar> and a user forces the use of multi
|
|
processor compilations for all ports in
|
|
<filename>/etc/make.conf</filename> with the
|
|
<literal>FORCE_MAKE_JOBS=yes</literal> variable.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="using-make">
|
|
<title><command>make</command>, <command>gmake</command>, and
|
|
<command>imake</command></title>
|
|
|
|
<para>If your port uses <application>GNU make</application>,
|
|
set <literal>USE_GMAKE=yes</literal>.</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports Related to
|
|
<application>gmake</application></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Means</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_GMAKE</makevar></entry>
|
|
<entry>The port requires <command>gmake</command> to
|
|
build.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>GMAKE</makevar></entry>
|
|
<entry>The full path for <command>gmake</command> if
|
|
it is not in the <envar>PATH</envar>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>If your port is an X application that creates
|
|
<filename>Makefile</filename> files from
|
|
<filename>Imakefile</filename> files using
|
|
<application>imake</application>, then set
|
|
<literal>USE_IMAKE=yes</literal>. This will cause the
|
|
configure stage to automatically do an <command>xmkmf
|
|
-a</command>. If the <option>-a</option> flag is a
|
|
problem for your port, set <literal>XMKMF=xmkmf</literal>.
|
|
If the port uses <application>imake</application> but does
|
|
not understand the <maketarget>install.man</maketarget>
|
|
target, <literal>NO_INSTALL_MANPAGES=yes</literal> should be
|
|
set.</para>
|
|
|
|
<para>If your port's source <filename>Makefile</filename> has
|
|
something else than <maketarget>all</maketarget> as the main
|
|
build target, set <makevar>ALL_TARGET</makevar> accordingly.
|
|
Same goes for <maketarget>install</maketarget> and
|
|
<makevar>INSTALL_TARGET</makevar>.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="using-configure">
|
|
<title><command>configure</command> Script</title>
|
|
|
|
<para>If your port uses the <command>configure</command>
|
|
script to generate <filename>Makefile</filename> files from
|
|
<filename>Makefile.in</filename> files, set
|
|
<literal>GNU_CONFIGURE=yes</literal>. If you want to give
|
|
extra arguments to the <command>configure</command> script
|
|
(the default argument is <literal>--prefix=${PREFIX}
|
|
--infodir=${PREFIX}/${INFO_PATH}
|
|
--mandir=${MANPREFIX}/man
|
|
--build=${CONFIGURE_TARGET}</literal>), set those
|
|
extra arguments in <makevar>CONFIGURE_ARGS</makevar>. Extra
|
|
environment variables can be passed using
|
|
<makevar>CONFIGURE_ENV</makevar> variable.</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use
|
|
<command>configure</command></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Means</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>GNU_CONFIGURE</makevar></entry>
|
|
<entry>The port uses <command>configure</command>
|
|
script to prepare build.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>HAS_CONFIGURE</makevar></entry>
|
|
<entry>Same as <makevar>GNU_CONFIGURE</makevar>,
|
|
except default configure target is not added to
|
|
<makevar>CONFIGURE_ARGS</makevar>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>CONFIGURE_ARGS</makevar></entry>
|
|
<entry>Additional arguments passed to
|
|
<command>configure</command> script.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>CONFIGURE_ENV</makevar></entry>
|
|
<entry>Additional environment variables to be set
|
|
for <command>configure</command> script run.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>CONFIGURE_TARGET</makevar></entry>
|
|
<entry>Override default configure target. Default
|
|
value is
|
|
<literal>${MACHINE_ARCH}-portbld-freebsd${OSREL}</literal>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2 id="using-scons">
|
|
<title>Using <command>scons</command></title>
|
|
|
|
<para>If your port uses <application>SCons</application>,
|
|
define <literal>USE_SCONS=yes</literal>.</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use
|
|
<command>scons</command></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Means</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>SCONS_ARGS</makevar></entry>
|
|
<entry>Port specific SCons flags passed to the SCons
|
|
environment.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>SCONS_BUILDENV</makevar></entry>
|
|
<entry>Variables to be set in system
|
|
environment.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>SCONS_ENV</makevar></entry>
|
|
<entry>Variables to be set in SCons
|
|
environment.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>SCONS_TARGET</makevar></entry>
|
|
<entry>Last argument passed to SCons, similar to
|
|
<makevar>MAKE_TARGET</makevar>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>To make third party <filename>SConstruct</filename>
|
|
respect everything that is passed to SCons in
|
|
<makevar>SCONS_ENV</makevar> (that is, most importantly,
|
|
<makevar>CC/CXX/CFLAGS/CXXFLAGS</makevar>), patch the
|
|
<filename>SConstruct</filename> so build
|
|
<literal>Environment</literal> is constructed like
|
|
this:</para>
|
|
|
|
<programlisting>env = Environment(**ARGUMENTS)</programlisting>
|
|
|
|
<para>It may be then modified with
|
|
<literal>env.Append</literal> and
|
|
<literal>env.Replace</literal>.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-autotools">
|
|
<title>Using GNU Autotools</title>
|
|
|
|
<sect2 id="using-autotools-introduction">
|
|
<title>Introduction</title>
|
|
|
|
<para>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:</para>
|
|
|
|
<programlisting>USE_AUTOTOOLS= <replaceable>tool</replaceable>:<replaceable>version</replaceable>[:<replaceable>operation</replaceable>] ...</programlisting>
|
|
|
|
<para>At the time of writing, <replaceable>tool</replaceable>
|
|
can be one of <literal>libtool</literal>,
|
|
<literal>libltdl</literal>, <literal>autoconf</literal>,
|
|
<literal>autoheader</literal>, <literal>automake</literal>
|
|
or <literal>aclocal</literal>.</para>
|
|
|
|
<para><replaceable>version</replaceable> specifies the
|
|
particular tool revision to be used (see
|
|
<literal>devel/{automake,autoconf,libtool}[0-9]+</literal>
|
|
for valid versions).</para>
|
|
|
|
<para><replaceable>operation</replaceable> is an optional
|
|
extension to modify how the tool is used.</para>
|
|
|
|
<para>Multiple tools can be specified at once, either by
|
|
including them all on a single line, or using the
|
|
<literal>+=</literal> Makefile construct.</para>
|
|
|
|
<para>Finally, there is the special tool, called
|
|
<literal>autotools</literal>, 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
|
|
<literal>devel/autotools</literal> port.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="using-libtool">
|
|
<title><command>libtool</command></title>
|
|
|
|
<para>Shared libraries using the GNU building framework
|
|
usually use <command>libtool</command> 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 <command>libtool</command>
|
|
bundled with the application. In case you need to use
|
|
external <command>libtool</command>, you can use the version
|
|
provided by The Ports Collection:</para>
|
|
|
|
<programlisting>USE_AUTOTOOLS= libtool:<replaceable>version</replaceable>[:env]</programlisting>
|
|
|
|
<para>With no additional operations,
|
|
<literal>libtool:<replaceable>version</replaceable></literal>
|
|
tells the building framework to patch the configure script
|
|
with the system-installed copy of
|
|
<command>libtool</command>. The
|
|
<makevar>GNU_CONFIGURE</makevar> is implied. Further, a
|
|
number of make and shell variables will be assigned for
|
|
onward use by the port. See
|
|
<filename>bsd.autotools.mk</filename> for details.</para>
|
|
|
|
<para>With the <literal>:env</literal> operation, only the
|
|
environment will be set up.</para>
|
|
|
|
<para>Finally, <makevar>LIBTOOLFLAGS</makevar> and
|
|
<makevar>LIBTOOLFILES</makevar> can be optionally set to
|
|
override the most likely arguments to, and files patched by,
|
|
<command>libtool</command>. Most ports are unlikely to need
|
|
this. See <filename>bsd.autotools.mk</filename> for further
|
|
details.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="using-libltdl">
|
|
<title><command>libltdl</command></title>
|
|
|
|
<para>Some ports make use of the <command>libltdl</command>
|
|
library package, which is part of the
|
|
<command>libtool</command> suite. Use of this library does
|
|
not automatically necessitate the use of
|
|
<command>libtool</command> itself, so a separate construct
|
|
is provided.</para>
|
|
|
|
<programlisting>USE_AUTOTOOLS= libltdl:<replaceable>version</replaceable></programlisting>
|
|
|
|
<para>Currently, all this does is to bring in a
|
|
<makevar>LIB_DEPENDS</makevar> on the appropriate
|
|
<command>libltdl</command> port, and is provided as a
|
|
convenience function to help eliminate any dependencies on
|
|
the autotools ports outside of the
|
|
<makevar>USE_AUTOTOOLS</makevar> framework. There are no
|
|
optional operations for this tool.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="using-autoconf">
|
|
<title><command>autoconf</command> and
|
|
<command>autoheader</command></title>
|
|
|
|
<para>Some ports do not contain a configure script, but do
|
|
contain an autoconf template in the
|
|
<filename>configure.ac</filename> file. You can use the
|
|
following assignments to let <command>autoconf</command>
|
|
create the configure script, and also have
|
|
<command>autoheader</command> create template headers for
|
|
use by the configure script.</para>
|
|
|
|
<programlisting>USE_AUTOTOOLS= autoconf:<replaceable>version</replaceable>[:env]</programlisting>
|
|
|
|
<para>and</para>
|
|
|
|
<programlisting>USE_AUTOTOOLS= autoheader:<replaceable>version</replaceable></programlisting>
|
|
|
|
<para>which also implies the use of
|
|
<literal>autoconf:<replaceable>version</replaceable></literal>.</para>
|
|
|
|
<para>Similarly to <command>libtool</command>, the inclusion
|
|
of the optional <literal>:env</literal> operation simply
|
|
sets up the environment for further use. Without it,
|
|
patching and reconfiguration of the port is carried
|
|
out.</para>
|
|
|
|
<para>The additional optional variables
|
|
<makevar>AUTOCONF_ARGS</makevar> and
|
|
<makevar>AUTOHEADER_ARGS</makevar> can be overridden by the
|
|
port <filename>Makefile</filename> if specifically
|
|
requested. As with the <command>libtool</command>
|
|
equivalents, most ports are unlikely to need this.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="using-automake">
|
|
<title><command>automake</command> and
|
|
<command>aclocal</command></title>
|
|
|
|
<para>Some packages only contain
|
|
<filename>Makefile.am</filename> files. These have to be
|
|
converted into <filename>Makefile.in</filename> files using
|
|
<command>automake</command>, and the further processed by
|
|
<command>configure</command> to generate an actual
|
|
<filename>Makefile</filename>.</para>
|
|
|
|
<para>Similarly, packages occasionally do not ship with
|
|
included <filename>aclocal.m4</filename> files, again
|
|
required to build the software. This can be achieved with
|
|
<command>aclocal</command>, which scans
|
|
<filename>configure.ac</filename> or
|
|
<filename>configure.in</filename>.</para>
|
|
|
|
<para><command>aclocal</command> has a similar relationship to
|
|
<command>automake</command> as <command>autoheader</command>
|
|
does to <command>autoconf</command>, described in the
|
|
previous section. <command>aclocal</command> implies the
|
|
use of <command>automake</command>, thus we have:</para>
|
|
|
|
<programlisting>USE_AUTOTOOLS= automake:<replaceable>version</replaceable>[:<replaceable>env</replaceable>]</programlisting>
|
|
|
|
<para>and</para>
|
|
|
|
<programlisting>USE_AUTOTOOLS= aclocal:<replaceable>version</replaceable></programlisting>
|
|
|
|
<para>which also implies the use of
|
|
<literal>automake:<replaceable>version</replaceable></literal>.</para>
|
|
|
|
<para>Similarly to <command>libtool</command> and
|
|
<command>autoconf</command>, the inclusion of the optional
|
|
<literal>:env</literal> operation simply sets up the
|
|
environment for further use. Without it, reconfiguration of
|
|
the port is carried out.</para>
|
|
|
|
<para>As with <command>autoconf</command> and
|
|
<command>autoheader</command>, both
|
|
<command>automake</command> and <command>aclocal</command>
|
|
have optional argument variables,
|
|
<makevar>AUTOMAKE_ARGS</makevar> and
|
|
<makevar>ACLOCAL_ARGS</makevar> respectively, which may be
|
|
overridden by the port <filename>Makefile</filename> if
|
|
required.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-pkg-config">
|
|
<title>Using <literal>pkg-config</literal></title>
|
|
|
|
<para>If your ports requires <literal>pkg-config</literal>,
|
|
just set <makevar>USE_PKGCONFIG</makevar> to the following
|
|
possible values:</para>
|
|
<table frame="none">
|
|
<title>Values for <makevar>USE_PKGCONFIG</makevar></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Definition</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_PKGCONFIG= yes</makevar></entry>
|
|
<entry>The ports uses pkg-config only at build time</entry>
|
|
</row>
|
|
<row>
|
|
<entry><makevar>USE_PKGCONFIG= build</makevar></entry>
|
|
<entry>The ports uses pkg-config only at build time</entry>
|
|
</row>
|
|
<row>
|
|
<entry><makevar>USE_PKGCONFIG= run</makevar></entry>
|
|
<entry>The ports uses pkg-config only at run time</entry>
|
|
</row>
|
|
<row>
|
|
<entry><makevar>USE_PKGCONFIG= both</makevar></entry>
|
|
<entry>The ports uses pkg-config both at build and run time</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect1>
|
|
|
|
<sect1 id="using-gettext">
|
|
<title>Using GNU <literal>gettext</literal></title>
|
|
|
|
<sect2>
|
|
<title>Basic Usage</title>
|
|
|
|
<para>If your port requires <literal>gettext</literal>,
|
|
just set <makevar>USE_GETTEXT</makevar> to
|
|
<literal>yes</literal>, and your port will grow the
|
|
dependency on <filename
|
|
role="package">devel/gettext</filename>. The value of
|
|
<makevar>USE_GETTEXT</makevar> can also specify the required
|
|
version of the <literal>libintl</literal> library, the basic
|
|
part of <literal>gettext</literal>, but using this feature
|
|
is <emphasis>strongly discouraged</emphasis>: Your port
|
|
should work with just the current version of <filename
|
|
role="package">devel/gettext</filename>.</para>
|
|
|
|
<para>A rather common case is a port using
|
|
<literal>gettext</literal> and <command>configure</command>.
|
|
Generally, GNU <command>configure</command> should be able
|
|
to locate <literal>gettext</literal> automatically. If it
|
|
ever fails to, hints at the location of
|
|
<literal>gettext</literal> can be passed in
|
|
<envar>CPPFLAGS</envar> and <envar>LDFLAGS</envar> as
|
|
follows:</para>
|
|
|
|
<programlisting>USE_GETTEXT= yes
|
|
CPPFLAGS+= -I${LOCALBASE}/include
|
|
LDFLAGS+= -L${LOCALBASE}/lib
|
|
|
|
GNU_CONFIGURE= yes
|
|
CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" \
|
|
LDFLAGS="${LDFLAGS}"</programlisting>
|
|
|
|
<para>Of course, the code can be more compact if there are no
|
|
more flags to pass to <command>configure</command>:</para>
|
|
|
|
<programlisting>USE_GETTEXT= yes
|
|
GNU_CONFIGURE= yes
|
|
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
|
|
LDFLAGS="-L${LOCALBASE}/lib"</programlisting>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Optional Usage</title>
|
|
|
|
<para>Some software products allow for disabling NLS, e.g.,
|
|
through passing <option>--disable-nls</option> to
|
|
<command>configure</command>. In that case, your port
|
|
should use <literal>gettext</literal> conditionally,
|
|
depending on the status of <link
|
|
linkend="knobs-without-nls"><makevar>WITHOUT_NLS</makevar></link>.
|
|
For ports of low to medium complexity, you can rely on the
|
|
following idiom:</para>
|
|
|
|
<programlisting>GNU_CONFIGURE= yes
|
|
|
|
.if !defined(WITHOUT_NLS)
|
|
USE_GETTEXT= yes
|
|
PLIST_SUB+= NLS=""
|
|
.else
|
|
CONFIGURE_ARGS+= --disable-nls
|
|
PLIST_SUB+= NLS="@comment "
|
|
.endif</programlisting>
|
|
|
|
<para>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 <filename>Makefile</filename> part of
|
|
this task is already provided by the idiom. It is explained
|
|
in the section on <link linkend="plist-sub">advanced
|
|
<filename>pkg-plist</filename> practices</link>. In a
|
|
nutshell, each occurrence of <literal>%%NLS%%</literal> in
|
|
<filename>pkg-plist</filename> will be replaced by
|
|
<quote><literal>@comment </literal></quote> if NLS is
|
|
disabled, or by a null string if NLS is enabled.
|
|
Consequently, the lines prefixed by
|
|
<literal>%%NLS%%</literal> 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
|
|
<literal>%%NLS%%</literal> before each path to a message
|
|
catalog file in <filename>pkg-plist</filename>. For
|
|
example:</para>
|
|
|
|
<programlisting>%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo
|
|
%%NLS%%share/locale/no/LC_MESSAGES/foobar.mo</programlisting>
|
|
|
|
<para>In high complexity cases, you may need to use more
|
|
advanced techniques than the recipe given here, such as
|
|
<link linkend="plist-dynamic">dynamic packing list
|
|
generation</link>.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Handling Message Catalog Directories</title>
|
|
|
|
<para>There is a point to note about installing message
|
|
catalog files. The target directories for them, which
|
|
reside under
|
|
<filename><makevar>LOCALBASE</makevar>/share/locale</filename>,
|
|
should rarely be created and removed by your port. The most
|
|
popular languages have their respective directories listed
|
|
in <filename>/etc/mtree/BSD.local.dist</filename>; that is,
|
|
they are a part of the base system. The directories for
|
|
many other languages are governed by the <filename
|
|
role="package">devel/gettext</filename> port. You may
|
|
want to consult its <filename>pkg-plist</filename> and see
|
|
whether your port is going to install a message catalog file
|
|
for a unique language.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-perl">
|
|
<title>Using <application>Perl</application></title>
|
|
|
|
<para>If <makevar>MASTER_SITES</makevar> is set to
|
|
<makevar>MASTER_SITE_PERL_CPAN</makevar>, then the preferred
|
|
value of <makevar>MASTER_SITE_SUBDIR</makevar> is the
|
|
top-level hierarchy name. For example, the recommended value
|
|
for <literal>p5-Module-Name</literal> is
|
|
<literal>Module</literal>. The top-level hierarchy can be
|
|
examined at <ulink
|
|
url="http://cpan.org/modules/by-module/">cpan.org</ulink>.
|
|
This keeps the port working when the author of the module
|
|
changes.</para>
|
|
|
|
<para>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
|
|
<makevar>MASTER_SITE_SUBDIR</makevar> is allowed.</para>
|
|
|
|
<para>All of the tunable knobs below accept either
|
|
<literal>YES</literal> or a version string like
|
|
<literal>5.8.0+</literal>. <literal>YES</literal> 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.,
|
|
<literal>5.7.3+</literal>), a maximum version (e.g.,
|
|
<literal>5.8.0-</literal>) or an exact version (e.g.,
|
|
<literal>5.8.3</literal>).</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use
|
|
<application>Perl</application></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Meaning</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_PERL5</makevar></entry>
|
|
<entry>The port uses Perl 5
|
|
to build and run.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_PERL5_BUILD</makevar></entry>
|
|
<entry>The port uses Perl 5
|
|
to build.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_PERL5_RUN</makevar></entry>
|
|
<entry>The port uses Perl 5
|
|
to run.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PERL</makevar></entry>
|
|
<entry>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 <quote><literal>#!</literal></quote>lines in
|
|
scripts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PERL_CONFIGURE</makevar></entry>
|
|
<entry>Configure using Perl's MakeMaker. It implies
|
|
<makevar>USE_PERL5</makevar>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PERL_MODBUILD</makevar></entry>
|
|
<entry>Configure, build and install using Module::Build.
|
|
It implies <makevar>PERL_CONFIGURE</makevar>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Read only variables</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>PERL_VERSION</makevar></entry>
|
|
<entry>The full version of Perl
|
|
installed (e.g., <literal>5.8.9</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PERL_LEVEL</makevar></entry>
|
|
<entry>The installed Perl version as
|
|
an integer of the form <literal>MNNNPP</literal>
|
|
(e.g., <literal>500809</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PERL_ARCH</makevar></entry>
|
|
<entry>Where Perl stores architecture
|
|
dependent libraries. Defaults to
|
|
<literal>${ARCH}-freebsd</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PERL_PORT</makevar></entry>
|
|
<entry>Name of the Perl port that is
|
|
installed (e.g., <literal>perl5</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>SITE_PERL</makevar></entry>
|
|
<entry>Directory name where site specific
|
|
Perl packages go. This value is
|
|
added to <makevar>PLIST_SUB</makevar>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<note>
|
|
<para>Ports of Perl modules which do not have an official
|
|
website should link to <hostid>cpan.org</hostid> in the WWW
|
|
line of <filename>pkg-descr</filename>. The
|
|
preferred URL form is
|
|
<literal>http://search.cpan.org/dist/Module-Name/</literal>
|
|
(including the trailing slash).</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>Do not use <literal>${SITE_PERL}</literal> in dependency
|
|
declarations. Doing so assumes that
|
|
<filename>bsd.perl.mk</filename> 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.</para>
|
|
</note>
|
|
|
|
<example id="use-perl-dependency-example">
|
|
<title>Perl Dependency Example</title>
|
|
|
|
<programlisting>p5-IO-Tee>=0.64:${PORTSDIR}/devel/p5-IO-Tee</programlisting>
|
|
</example>
|
|
</sect1>
|
|
|
|
<sect1 id="using-x11">
|
|
<title>Using X11</title>
|
|
|
|
<sect2 id="x11-variables">
|
|
<title>X.Org Components</title>
|
|
|
|
<para>The X11 implementation available in The Ports Collection
|
|
is X.Org. If your application depends on X components, set
|
|
<makevar>USE_XORG</makevar> to the list of required
|
|
components. Available components, at the time of writing,
|
|
are:</para>
|
|
|
|
<para><literal>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</literal>.</para>
|
|
|
|
<para>Always up-to-date list can be found in
|
|
<filename>/usr/ports/Mk/bsd.xorg.mk</filename>.</para>
|
|
|
|
<para>The Mesa Project is an effort to provide free OpenGL
|
|
implementation. You can specify a dependency on various
|
|
components of this project with <makevar>USE_GL</makevar>
|
|
variable. Valid options are: <literal>glut, glu, glw, glew,
|
|
gl</literal> and <literal>linux</literal>. For backwards
|
|
compatibility, the value of <literal>yes</literal> maps to
|
|
<literal>glu</literal>.</para>
|
|
|
|
<example id="use-xorg-example">
|
|
<title>USE_XORG Example</title>
|
|
|
|
<programlisting>USE_XORG= xrender xft xkbfile xt xaw
|
|
USE_GL= glu</programlisting>
|
|
</example>
|
|
|
|
<para>Some ports define <makevar>USE_XLIB</makevar>, which
|
|
makes the port depend on all the 50 or so libraries. This
|
|
variable exists for backwards compatibility, as it predates
|
|
modular X.Org, and should not be used on new ports.</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use X</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_XLIB</makevar></entry>
|
|
<entry>The port uses the X libraries. Deprecated -
|
|
use a list of X.Org components in
|
|
<makevar>USE_XORG</makevar> variable
|
|
instead.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_IMAKE</makevar></entry>
|
|
<entry>The port uses <command>imake</command>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>XMKMF</makevar></entry>
|
|
<entry>Set to the path of <command>xmkmf</command> if
|
|
not in the <envar>PATH</envar>. Defaults to
|
|
<literal>xmkmf -a</literal>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Depending on Individual Parts of
|
|
X11</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>X_IMAKE_PORT</makevar></entry>
|
|
<entry>Port providing <command>imake</command> and
|
|
several other utilities used to build X11.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_LIBRARIES_PORT</makevar></entry>
|
|
<entry>Port providing X11 libraries.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_CLIENTS_PORT</makevar></entry>
|
|
<entry>Port providing X clients.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_SERVER_PORT</makevar></entry>
|
|
<entry>Port providing X server.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTSERVER_PORT</makevar></entry>
|
|
<entry>Port providing font server.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_PRINTSERVER_PORT</makevar></entry>
|
|
<entry>Port providing print server.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_VFBSERVER_PORT</makevar></entry>
|
|
<entry>Port providing virtual framebuffer
|
|
server.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_NESTSERVER_PORT</makevar></entry>
|
|
<entry>Port providing a nested X server.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTS_ENCODINGS_PORT</makevar></entry>
|
|
<entry>Port providing encodings for fonts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTS_MISC_PORT</makevar></entry>
|
|
<entry>Port providing miscellaneous bitmap
|
|
fonts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTS_100DPI_PORT</makevar></entry>
|
|
<entry>Port providing 100dpi bitmap fonts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTS_75DPI_PORT</makevar></entry>
|
|
<entry>Port providing 75dpi bitmap fonts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTS_CYRILLIC_PORT</makevar></entry>
|
|
<entry>Port providing cyrillic bitmap fonts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTS_TTF_PORT</makevar></entry>
|
|
<entry>Port providing &truetype; fonts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_FONTS_TYPE1_PORT</makevar></entry>
|
|
<entry>Port providing Type1 fonts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>X_MANUALS_PORT</makevar></entry>
|
|
<entry>Port providing developer oriented manual
|
|
pages</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<example id="using-x11-vars">
|
|
<title>Using X11-Related Variables</title>
|
|
|
|
<programlisting># Use some X11 libraries and depend on
|
|
# font server as well as cyrillic fonts.
|
|
RUN_DEPENDS= ${LOCALBASE}/bin/xfs:${X_FONTSERVER_PORT} \
|
|
${LOCALBASE}/lib/X11/fonts/cyrillic/crox1c.pcf.gz:${X_FONTS_CYRILLIC_PORT}
|
|
|
|
USE_XORG= x11 xpm</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="x11-motif">
|
|
<title>Ports That Require Motif</title>
|
|
|
|
<para>If your port requires a Motif library, define
|
|
<makevar>USE_MOTIF</makevar> in the
|
|
<filename>Makefile</filename>. Default Motif implementation
|
|
is <filename
|
|
role="package">x11-toolkits/open-motif</filename>. Users
|
|
can choose <filename
|
|
role="package">x11-toolkits/lesstif</filename> instead by
|
|
setting <makevar>WANT_LESSTIF</makevar> variable.</para>
|
|
|
|
<para>The <makevar>MOTIFLIB</makevar> variable will be set by
|
|
<filename>bsd.port.mk</filename> to reference the
|
|
appropriate Motif library. Please patch the source of your
|
|
port to use <literal>${MOTIFLIB}</literal> wherever
|
|
the Motif library is referenced in the original
|
|
<filename>Makefile</filename> or
|
|
<filename>Imakefile</filename>.</para>
|
|
|
|
<para>There are two common cases:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If the port refers to the Motif library as
|
|
<literal>-lXm</literal> in its
|
|
<filename>Makefile</filename> or
|
|
<filename>Imakefile</filename>, simply substitute
|
|
<literal>${MOTIFLIB}</literal> for it.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the port uses <literal>XmClientLibs</literal> in
|
|
its <filename>Imakefile</filename>, change it to
|
|
<literal>${MOTIFLIB} ${XTOOLLIB}
|
|
${XLIB}</literal>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Note that <makevar>MOTIFLIB</makevar> (usually) expands
|
|
to <literal>-L/usr/local/lib -lXm</literal> or
|
|
<literal>/usr/local/lib/libXm.a</literal>, so there is no
|
|
need to add <literal>-L</literal> or <literal>-l</literal>
|
|
in front.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>X11 Fonts</title>
|
|
|
|
<para>If your port installs fonts for the X Window System, put
|
|
them in
|
|
<filename><makevar>LOCALBASE</makevar>/lib/X11/fonts/local</filename>.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Getting a Fake <envar>DISPLAY</envar> with Xvfb</title>
|
|
|
|
<para>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 <envar>DISPLAY</envar> is then passed
|
|
to the build.</para>
|
|
|
|
<programlisting>USE_DISPLAY= yes</programlisting>
|
|
</sect2>
|
|
|
|
<sect2 id="desktop-entries">
|
|
<title>Desktop Entries</title>
|
|
|
|
<para>Desktop entries (<ulink
|
|
url="http://standards.freedesktop.org/desktop-entry-spec/latest/">a
|
|
Freedesktop standard</ulink>) 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
|
|
<application>GNOME</application> desktop environment, but
|
|
are now a standard and also work with
|
|
<application>KDE</application> and
|
|
<application>Xfce</application>. 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.</para>
|
|
|
|
<sect3>
|
|
<title>Using Predefined <filename>.desktop</filename>
|
|
Files</title>
|
|
|
|
<para>Ports that include predefined
|
|
<filename>*.desktop</filename> files should
|
|
include those files in <filename>pkg-plist</filename>
|
|
and install them in the
|
|
<filename><makevar>$LOCALBASE</makevar>/share/applications</filename>
|
|
directory. The <link
|
|
linkend="install-macros"><makevar>INSTALL_DATA</makevar>
|
|
macro</link> is useful for installing these
|
|
files.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="desktop-entries-macro">
|
|
<title>Creating Desktop Entries with the
|
|
<makevar>DESKTOP_ENTRIES</makevar> Macro</title>
|
|
|
|
<para>Desktop entries can be easily created for applications
|
|
by using the <makevar>DESKTOP_ENTRIES</makevar> variable.
|
|
A file named
|
|
<filename><replaceable>name</replaceable>.desktop</filename>
|
|
will be created, installed, and added to the
|
|
<filename>pkg-plist</filename> automatically. Syntax
|
|
is:</para>
|
|
|
|
<programlisting>DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify</programlisting>
|
|
|
|
<para>The list of possible categories is available on the
|
|
<ulink
|
|
url="http://standards.freedesktop.org/menu-spec/latest/apa.html">Freedesktop
|
|
website</ulink>. <makevar>StartupNotify</makevar>
|
|
indicates whether the application is compatible with
|
|
<emphasis>startup notifications</emphasis>. 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 <makevar>StartupNotify</makevar> set to
|
|
<literal>false</literal> so the indicator is not shown at
|
|
all.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting>DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \
|
|
"${DATADIR}/xtra/graf/tome-128.png" \
|
|
"tome -v -g" "Application;Game;RolePlaying;" \
|
|
false</programlisting>
|
|
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-gnome">
|
|
<title>Using GNOME</title>
|
|
|
|
<para>The FreeBSD/GNOME project uses its own set of variables to
|
|
define which GNOME components a particular port uses. A
|
|
<ulink
|
|
url="http://www.FreeBSD.org/gnome/docs/porting.html">comprehensive
|
|
list of these variables</ulink> exists within the
|
|
FreeBSD/GNOME project's homepage.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="using-qt">
|
|
<title>Using Qt</title>
|
|
|
|
<sect2 id="qt-common">
|
|
<title>Ports That Require Qt</title>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use Qt</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_QT_VER</makevar></entry>
|
|
<entry>The port uses the Qt toolkit. Possible values
|
|
are <literal>3</literal> and <literal>4</literal>;
|
|
each specify the major version of Qt to use.
|
|
Appropriate parameters are passed to
|
|
<command>configure</command> script and
|
|
<command>make</command>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>QT_PREFIX</makevar></entry>
|
|
<entry>Set to the path where Qt installed to
|
|
(read-only variable).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>MOC</makevar></entry>
|
|
<entry>Set to the path of <command>moc</command>
|
|
(read-only variable). Default set according to
|
|
<makevar>USE_QT_VER</makevar> value.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>QTCPPFLAGS</makevar></entry>
|
|
<entry>Additional compiler flags passed via
|
|
<makevar>CONFIGURE_ENV</makevar> for Qt toolkit.
|
|
Default set according to
|
|
<makevar>USE_QT_VER</makevar>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>QTCFGLIBS</makevar></entry>
|
|
<entry>Additional libraries for linking passed via
|
|
<makevar>CONFIGURE_ENV</makevar> for Qt toolkit.
|
|
Default set according to
|
|
<makevar>USE_QT_VER</makevar>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>QTNONSTANDARD</makevar></entry>
|
|
<entry>Suppress modification of
|
|
<makevar>CONFIGURE_ENV</makevar>,
|
|
<makevar>CONFIGURE_ARGS</makevar>,
|
|
<makevar>CPPFLAGS</makevar> and
|
|
<makevar>MAKE_ENV</makevar>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="none">
|
|
<title>Additional Variables for Ports That Use Qt
|
|
4.x</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>QT_COMPONENTS</makevar></entry>
|
|
<entry>Specify tool and library dependencies for Qt 4.
|
|
See below for details.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>UIC</makevar></entry>
|
|
<entry>Set to the path of <command>uic</command>
|
|
(read-only variable).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>QMAKE</makevar></entry>
|
|
<entry>Set to the path of <command>qmake</command>
|
|
(read-only variable).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>QMAKESPEC</makevar></entry>
|
|
<entry>Set to the path of configuration file for
|
|
<command>qmake</command> (read-only
|
|
variable).</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>When <makevar>USE_QT_VER</makevar> is set, some useful
|
|
settings are passed to <command>configure</command>
|
|
script:</para>
|
|
|
|
<programlisting>CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \
|
|
--with-qt-libraries=${QT_PREFIX}/lib \
|
|
--with-extra-libs=${LOCALBASE}/lib \
|
|
--with-extra-includes=${LOCALBASE}/include
|
|
CONFIGURE_ENV+= MOC="${MOC}" LIBS="${QTCFGLIBS}" \
|
|
QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}"
|
|
CPPFLAGS+= ${QTCPPFLAGS}</programlisting>
|
|
|
|
<para>If <makevar>USE_QT_VER</makevar> is set to
|
|
<literal>4</literal>, the following settings are also
|
|
deployed:</para>
|
|
|
|
<programlisting>CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}"
|
|
MAKE_ENV+= QMAKESPEC="${QMAKESPEC}"</programlisting>
|
|
</sect2>
|
|
|
|
<sect2 id="qt4-components">
|
|
<title>Component Selection (Qt 4.x Only)</title>
|
|
|
|
<para>When <makevar>USE_QT_VER</makevar> is set to
|
|
<literal>4</literal>, individual Qt 4 tool and library
|
|
dependencies can be specified in the
|
|
<makevar>QT_COMPONENTS</makevar> variable. Every component
|
|
can be suffixed by either <literal>_build</literal> or
|
|
<literal>_run</literal>, 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 <literal>_build</literal> suffix and
|
|
plugin components should be specified with the
|
|
<literal>_run</literal> suffix. The most commonly used
|
|
components are listed below (all available components are
|
|
listed in <makevar>_QT_COMPONENTS_ALL</makevar> in
|
|
<filename>/usr/ports/Mk/bsd.qt.mk</filename>):</para>
|
|
|
|
<table frame="none">
|
|
<title>Available Qt 4 Library Components</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>corelib</literal></entry>
|
|
<entry>core library (can be omitted unless the port
|
|
uses nothing but <literal>corelib</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>gui</literal></entry>
|
|
<entry>graphical user interface library</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>network</literal></entry>
|
|
<entry>network library</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>opengl</literal></entry>
|
|
<entry>OpenGL library</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>qt3support</literal></entry>
|
|
<entry>Qt 3 compatibility library</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>qtestlib</literal></entry>
|
|
<entry>unit testing library</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>script</literal></entry>
|
|
<entry>script library</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>sql</literal></entry>
|
|
<entry>SQL library</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>xml</literal></entry>
|
|
<entry>XML library</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>You can determine which libraries the application
|
|
depends on, by running <command>ldd</command> on the main
|
|
executable after a successful compilation.</para>
|
|
|
|
<table frame="none">
|
|
<title>Available Qt 4 Tool Components</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>moc</literal></entry>
|
|
<entry>meta object compiler (needed for almost
|
|
every Qt application at buildtime)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>qmake</literal></entry>
|
|
<entry>Makefile generator / build utility</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>rcc</literal></entry>
|
|
<entry>resource compiler (needed if the application
|
|
comes with <filename>*.rc</filename> or
|
|
<filename>*.qrc</filename> files)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>uic</literal></entry>
|
|
<entry>user interface compiler (needed if the
|
|
application comes with <filename>*.ui</filename>
|
|
files created by Qt Designer - in practice, every Qt
|
|
application with a GUI)</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="none">
|
|
<title>Available Qt 4 Plugin Components</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>iconengines</literal></entry>
|
|
<entry>SVG icon engine plugin (if the application
|
|
ships SVG icons)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>imageformats</literal></entry>
|
|
<entry>imageformat plugins for GIF, JPEG, MNG and
|
|
SVG (if the application ships image files)</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<example id="qt4-components-example">
|
|
<title>Selecting Qt 4 Components</title>
|
|
|
|
<para>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 <literal>gui</literal> library
|
|
implies a dependency on the core library,
|
|
<literal>corelib</literal> does not need to be specified.
|
|
The Qt 4 code generation tools <literal>moc</literal>,
|
|
<literal>uic</literal> and <literal>rcc</literal>, as well
|
|
as the Makefile generator <literal>qmake</literal> are
|
|
only needed at buildtime, thus they are specified with the
|
|
<literal>_build</literal> suffix:</para>
|
|
|
|
<programlisting>USE_QT_VER= 4
|
|
QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="qt-additional">
|
|
<title>Additional Considerations</title>
|
|
|
|
<para>If the application does not provide a
|
|
<filename>configure</filename> file but a
|
|
<filename>.pro</filename> file, you can use the
|
|
following:</para>
|
|
|
|
<programlisting>HAS_CONFIGURE= yes
|
|
|
|
do-configure:
|
|
@cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
|
|
${QMAKE} PREFIX=${PREFIX} texmaker.pro</programlisting>
|
|
|
|
<para>Note the similarity to the <command>qmake</command> line
|
|
from the provided <filename>BUILD.sh</filename> script.
|
|
Passing <makevar>CONFIGURE_ENV</makevar> ensures
|
|
<command>qmake</command> will see the
|
|
<makevar>QMAKESPEC</makevar> variable, without which it
|
|
cannot work. <command>qmake</command> generates standard
|
|
Makefiles, so it is not necessary to write our own
|
|
<maketarget>build</maketarget> target.</para>
|
|
|
|
<para>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:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis>Missing additional include
|
|
paths.</emphasis> Many applications come with
|
|
system tray icon support, but neglect to look for
|
|
includes and/or libraries in the X11 directories. You
|
|
can tell <command>qmake</command> to add directories to
|
|
the include and library search paths via the command
|
|
line, for example:</para>
|
|
|
|
<programlisting>${QMAKE} PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \
|
|
LIBS+=-L${LOCALBASE}/lib sillyapp.pro</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>Bogus installation paths.</emphasis>
|
|
Sometimes data such as icons or .desktop files are by
|
|
default installed into directories which are not scanned
|
|
by XDG-compatible applications. <filename
|
|
role="package">editors/texmaker</filename> is an
|
|
example for this - look at
|
|
<filename>patch-texmaker.pro</filename> in the
|
|
<filename>files</filename> directory of that port for a
|
|
template on how to remedy this directly in the
|
|
<command>qmake</command> project file.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-kde">
|
|
<title>Using KDE</title>
|
|
|
|
<sect2 id="kde-variables">
|
|
<title>Variable Definitions (KDE 3.x Only)</title>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use KDE 3.x</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_KDELIBS_VER</makevar></entry>
|
|
<entry>The port uses KDE libraries. It specifies the
|
|
major version of KDE to use and implies
|
|
<makevar>USE_QT_VER</makevar> of the appropriate
|
|
version. The only possible value is
|
|
<literal>3</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_KDEBASE_VER</makevar></entry>
|
|
<entry>The port uses KDE base. It specifies the major
|
|
version of KDE to use and implies
|
|
<makevar>USE_QT_VER</makevar> of the appropriate
|
|
version. The only possible value is
|
|
<literal>3</literal>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2 id="kde4-variables">
|
|
<title>KDE 4 Variable Definitions</title>
|
|
|
|
<para>If your application depends on KDE 4.x, set
|
|
<makevar>USE_KDE4</makevar> to the list of required
|
|
components. <literal>_build</literal> and
|
|
<literal>_run</literal> suffixes can be used to force
|
|
components dependency type (e.g.,
|
|
<literal>baseapps_run</literal>). 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., <literal>automoc4_build automoc4_run</literal>). The
|
|
most commonly used components are listed below (up-to-date
|
|
components are documented at the top of
|
|
<filename>/usr/ports/Mk/bsd.kde4.mk</filename>):</para>
|
|
|
|
<table frame="none">
|
|
<title>Available KDE 4 Components</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>baseapps</literal></entry>
|
|
<entry>Basic applications for KDE Desktop</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>kdehier</literal></entry>
|
|
<entry>Hierarchy of common KDE directories</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>kdelibs</literal></entry>
|
|
<entry>KDE Developer Platform</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>kdeprefix</literal></entry>
|
|
<entry>If set, port will be installed into
|
|
<literal>${KDE4_PREFIX}</literal> instead of
|
|
<literal>${LOCALBASE}</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>pimlibs</literal></entry>
|
|
<entry>KDE-Pim libraries</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>workspace</literal></entry>
|
|
<entry>KDE user environments</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>akonadi</literal></entry>
|
|
<entry>Storage server for KDE-Pim</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>automoc4</literal></entry>
|
|
<entry>Automatic moc for Qt 4 packages</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>KDE 4.x ports are installed into
|
|
<makevar>KDE4_PREFIX</makevar>, which is
|
|
<filename>/usr/local/kde4</filename> currently, to avoid
|
|
conflicts with KDE 3.x ports. This is achieved by
|
|
specifying the <literal>kdeprefix</literal> component, which
|
|
overrides the default <makevar>PREFIX</makevar>. The ports
|
|
however respect any <makevar>PREFIX</makevar> set via
|
|
<envar>MAKEFLAGS</envar> environment variable and/or
|
|
<command>make</command> arguments.</para>
|
|
|
|
<example id="kde4-components-example">
|
|
<title><makevar>USE_KDE4</makevar> Example</title>
|
|
|
|
<para>This is a simple example for a KDE 4 port.
|
|
<makevar>USE_CMAKE</makevar> instructs the port to utilize
|
|
<application>CMake</application> — configuration
|
|
tool widely spread among KDE 4 projects.
|
|
<makevar>USE_KDE4</makevar> brings dependency on KDE
|
|
libraries and makes port using
|
|
<command>automoc4</command> at build stage.
|
|
Required KDE components and other dependencies can be
|
|
determined through configure log.
|
|
<makevar>USE_KDE4</makevar> does not imply
|
|
<makevar>USE_QT_VER</makevar>. If a port requires some
|
|
Qt 4 components, <makevar>USE_QT_VER</makevar> should be
|
|
set and then needed components can be specified.</para>
|
|
|
|
<programlisting>USE_CMAKE= yes
|
|
USE_KDE4= kdelibs kdeprefix automoc4
|
|
USE_QT_VER= 4
|
|
QT_COMPONENTS= moc_build qmake_build rcc_build uic_build</programlisting>
|
|
</example>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-java">
|
|
<title>Using Java</title>
|
|
|
|
<sect2 id="java-variables">
|
|
<title>Variable Definitions</title>
|
|
|
|
<para>If your port needs a Java™ Development Kit
|
|
(JDK™) to either build, run or even extract the
|
|
distfile, then it should define
|
|
<makevar>USE_JAVA</makevar>.</para>
|
|
|
|
<para>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 is <filename
|
|
role="package">java/jdk16</filename>.</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables Which May be Set by Ports That Use
|
|
Java</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Means</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_JAVA</makevar></entry>
|
|
<entry>Should be defined for the remaining variables
|
|
to have any effect.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_VERSION</makevar></entry>
|
|
<entry>List of space-separated suitable Java versions
|
|
for the port. An optional <literal>"+"</literal>
|
|
allows you to specify a range of versions (allowed
|
|
values:
|
|
<literal>1.5[+] 1.6[+] 1.7[+]</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_OS</makevar></entry>
|
|
<entry>List of space-separated suitable JDK port
|
|
operating systems for the port (allowed values:
|
|
<literal>native linux</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_VENDOR</makevar></entry>
|
|
<entry>List of space-separated suitable JDK port
|
|
vendors for the port (allowed values:
|
|
<literal>freebsd bsdjava sun
|
|
openjdk</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_BUILD</makevar></entry>
|
|
<entry>When set, it means that the selected JDK port
|
|
should be added to the build dependencies of the
|
|
port.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_RUN</makevar></entry>
|
|
<entry>When set, it means that the selected JDK port
|
|
should be added to the run dependencies of the
|
|
port.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_EXTRACT</makevar></entry>
|
|
<entry>When set, it means that the selected JDK port
|
|
should be added to the extract dependencies of the
|
|
port.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Below is the list of all settings a port will receive
|
|
after setting <makevar>USE_JAVA</makevar>:</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables Provided to Ports That Use Java</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Value</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>JAVA_PORT</makevar></entry>
|
|
<entry>The name of the JDK port (e.g.
|
|
<literal>'java/openjdk6'</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_PORT_VERSION</makevar></entry>
|
|
<entry>The full version of the JDK port (e.g.
|
|
<literal>'1.6.0'</literal>). If you only need the
|
|
first two digits of this version number, use
|
|
<makevar>${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}</makevar>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_PORT_OS</makevar></entry>
|
|
<entry>The operating system used by the JDK port (e.g.
|
|
<literal>'native'</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_PORT_VENDOR</makevar></entry>
|
|
<entry>The vendor of the JDK port (e.g.
|
|
<literal>'openjdk'</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_PORT_OS_DESCRIPTION</makevar></entry>
|
|
<entry>Description of the operating system used by the
|
|
JDK port (e.g.,
|
|
<literal>'Native'</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_PORT_VENDOR_DESCRIPTION</makevar></entry>
|
|
<entry>Description of the vendor of the JDK port (e.g.
|
|
<literal>'OpenJDK BSD Porting
|
|
Team'</literal>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_HOME</makevar></entry>
|
|
<entry>Path to the installation directory of the JDK
|
|
(e.g.
|
|
<filename>'/usr/local/openjdk6'</filename>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVAC</makevar></entry>
|
|
<entry>Path to the Java compiler to use (e.g.
|
|
<filename>'/usr/local/openjdk6/bin/javac'</filename>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAR</makevar></entry>
|
|
<entry>Path to the <command>jar</command> tool to use
|
|
(e.g.
|
|
<filename>'/usr/local/openjdk6/bin/jar'</filename>
|
|
or
|
|
<filename>'/usr/local/bin/fastjar'</filename>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>APPLETVIEWER</makevar></entry>
|
|
<entry>Path to the <command>appletviewer</command>
|
|
utility (e.g.
|
|
<filename>'/usr/local/openjdk6/bin/appletviewer'</filename>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA</makevar></entry>
|
|
<entry>Path to the <command>java</command> executable.
|
|
Use this for executing Java programs (e.g.
|
|
<filename>'/usr/local/openjdk6/bin/java'</filename>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVADOC</makevar></entry>
|
|
<entry>Path to the <command>javadoc</command> utility
|
|
program.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVAH</makevar></entry>
|
|
<entry>Path to the <command>javah</command>
|
|
program.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVAP</makevar></entry>
|
|
<entry>Path to the <command>javap</command>
|
|
program.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_KEYTOOL</makevar></entry>
|
|
<entry>Path to the <command>keytool</command> utility
|
|
program.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_N2A</makevar></entry>
|
|
<entry>Path to the <command>native2ascii</command>
|
|
tool.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_POLICYTOOL</makevar></entry>
|
|
<entry>Path to the <command>policytool</command>
|
|
program.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_SERIALVER</makevar></entry>
|
|
<entry>Path to the <command>serialver</command>
|
|
utility program.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RMIC</makevar></entry>
|
|
<entry>Path to the RMI stub/skeleton generator,
|
|
<command>rmic</command>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RMIREGISTRY</makevar></entry>
|
|
<entry>Path to the RMI registry program,
|
|
<command>rmiregistry</command>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RMID</makevar></entry>
|
|
<entry>Path to the RMI daemon program
|
|
<command>rmid</command>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVA_CLASSES</makevar></entry>
|
|
<entry>Path to the archive that contains the JDK class
|
|
files,
|
|
<filename>${JAVA_HOME}/jre/lib/rt.jar</filename>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>You may use the <literal>java-debug</literal> make
|
|
target to get information for debugging your port. It will
|
|
display the value of many of the forecited variables.</para>
|
|
|
|
<para>Additionally, the following constants are defined so all
|
|
Java ports may be installed in a consistent way:</para>
|
|
|
|
<table frame="none">
|
|
<title>Constants Defined for Ports That Use Java</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Constant</entry>
|
|
<entry>Value</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>JAVASHAREDIR</makevar></entry>
|
|
<entry>The base directory for everything related to
|
|
Java. Default:
|
|
<filename>${PREFIX}/share/java</filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVAJARDIR</makevar></entry>
|
|
<entry>The directory where JAR files should be
|
|
installed. Default:
|
|
<filename>${JAVASHAREDIR}/classes</filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>JAVALIBDIR</makevar></entry>
|
|
<entry>The directory where JAR files installed by
|
|
other ports are located. Default:
|
|
<filename>${LOCALBASE}/share/java/classes</filename>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>The related entries are defined in both
|
|
<makevar>PLIST_SUB</makevar> (documented in
|
|
<xref linkend="plist-sub"/>) and
|
|
<makevar>SUB_LIST</makevar>.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="java-building-with-ant">
|
|
<title>Building with Ant</title>
|
|
|
|
<para>When the port is to be built using Apache Ant, it has to
|
|
define <makevar>USE_ANT</makevar>. Ant is thus considered
|
|
to be the sub-make command. When no
|
|
<literal>do-build</literal> target is defined by the port, a
|
|
default one will be set that simply runs Ant according to
|
|
<makevar>MAKE_ENV</makevar>, <makevar>MAKE_ARGS</makevar>
|
|
and <makevar>ALL_TARGET</makevar>. This is similar to the
|
|
<makevar>USE_GMAKE</makevar> mechanism, which is documented
|
|
in <xref linkend="building"/>.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="java-best-practices">
|
|
<title>Best Practices</title>
|
|
|
|
<para>When porting a Java library, your port should install
|
|
the JAR file(s) in <filename>${JAVAJARDIR}</filename>, and
|
|
everything else under
|
|
<filename>${JAVASHAREDIR}/${PORTNAME}</filename> (except for
|
|
the documentation, see below). In order to reduce the
|
|
packing file size, you may reference the JAR file(s)
|
|
directly in the <filename>Makefile</filename>. Just use the
|
|
following statement (where <filename>myport.jar</filename>
|
|
is the name of the JAR file installed as part of the
|
|
port):</para>
|
|
|
|
<programlisting>PLIST_FILES+= %%JAVAJARDIR%%/myport.jar</programlisting>
|
|
|
|
<para>When porting a Java application, the port usually
|
|
installs everything under a single directory (including its
|
|
JAR dependencies). The use of
|
|
<filename>${JAVASHAREDIR}/${PORTNAME}</filename> 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
|
|
<filename>${JAVAJARDIR}</filename>).</para>
|
|
|
|
<para>Regardless of the type of your port (library or
|
|
application), the additional documentation should be
|
|
installed in the <link linkend="install-documentation">same
|
|
location</link> 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
|
|
(<filename>pkg-plist</filename>). This is one reason why
|
|
porters are strongly encouraged to use the
|
|
<makevar>PORTDOCS</makevar> macro. Moreover, even if you
|
|
can predict the set of files that will be generated by
|
|
<command>javadoc</command>, the size of the resulting
|
|
<filename>pkg-plist</filename> advocates for the use of
|
|
<makevar>PORTDOCS</makevar>.</para>
|
|
|
|
<para>The default value for <makevar>DATADIR</makevar> is
|
|
<filename>${PREFIX}/share/${PORTNAME}</filename>. It is a
|
|
good idea to override <makevar>DATADIR</makevar> to
|
|
<filename>${JAVASHAREDIR}/${PORTNAME}</filename> for Java
|
|
ports. Indeed, <makevar>DATADIR</makevar> is automatically
|
|
added to <makevar>PLIST_SUB</makevar> (documented in <xref
|
|
linkend="plist-sub"/>) so you may use
|
|
<literal>%%DATADIR%%</literal> directly in
|
|
<filename>pkg-plist</filename>.</para>
|
|
|
|
<para>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 <ulink
|
|
url="http://www.freebsd.org/java/">&os; Java
|
|
Project</ulink> encourage porters to have their ports built
|
|
from source whenever it is a trivial task.</para>
|
|
|
|
<para>All the features that have been presented in this
|
|
section are implemented in <filename>bsd.java.mk</filename>.
|
|
If you ever think that your port needs more sophisticated
|
|
Java support, please first have a look at the <ulink
|
|
url="http://svn.FreeBSD.org/ports/head/Mk/bsd.java.mk?view=markup">bsd.java.mk
|
|
SVN log</ulink> 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;.</para>
|
|
|
|
<para>Although there is a <literal>java</literal> category for
|
|
PRs, it refers to the JDK porting effort from the &os; Java
|
|
project. Therefore, you should submit your Java port in the
|
|
<literal>ports</literal> category as for any other port,
|
|
unless the issue you are trying to resolve is related to
|
|
either a JDK implementation or
|
|
<filename>bsd.java.mk</filename>.</para>
|
|
|
|
<para>Similarly, there is a defined policy regarding the
|
|
<makevar>CATEGORIES</makevar> of a Java port, which is
|
|
detailed in <xref linkend="makefile-categories"/>.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-php">
|
|
<title>Web Applications, Apache and PHP</title>
|
|
|
|
<sect2 id="using-apache">
|
|
<title>Apache</title>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use Apache</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry><makevar>USE_APACHE</makevar></entry>
|
|
<entry>The port requires Apache. Possible values:
|
|
<literal>yes</literal> (gets any version),
|
|
<literal>20</literal>, <literal>22</literal>,
|
|
<literal>20-22</literal>, <literal>20+</literal>,
|
|
etc. The default APACHE version is
|
|
<literal>22</literal>. More details are available in
|
|
<filename>ports/Mk/bsd.apache.mk</filename> and at
|
|
<ulink url="http://wiki.freebsd.org/Apache/">wiki.freebsd.org/Apache/</ulink>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_APACHE2</makevar></entry>
|
|
<entry>This variable is deprecated and should
|
|
not be used any more.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>APXS</makevar></entry>
|
|
<entry>Full path to the <command>apxs</command>
|
|
binary. Can be overridden in your port.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>HTTPD</makevar></entry>
|
|
<entry>Full path to the <command>httpd</command>
|
|
binary. Can be overridden in your port.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>APACHE_VERSION</makevar></entry>
|
|
<entry>The version of present Apache installation
|
|
(read-only variable). This variable is only
|
|
available after inclusion of
|
|
<filename>bsd.port.pre.mk</filename>. Possible
|
|
values: <literal>20</literal>,
|
|
<literal>22</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>APACHEMODDIR</makevar></entry>
|
|
<entry>Directory for Apache modules. This variable is
|
|
automatically expanded in
|
|
<filename>pkg-plist</filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>APACHEINCLUDEDIR</makevar></entry>
|
|
<entry>Directory for Apache headers. This variable is
|
|
automatically expanded in
|
|
<filename>pkg-plist</filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>APACHEETCDIR</makevar></entry>
|
|
<entry>Directory for Apache configuration files. This
|
|
variable is automatically expanded in
|
|
<filename>pkg-plist</filename>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<table frame="none">
|
|
<title>Useful Variables for Porting Apache Modules</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry><makevar>MODULENAME</makevar></entry>
|
|
<entry>Name of the module. Default value is
|
|
<makevar>PORTNAME</makevar>. Example:
|
|
<literal>mod_hello</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>SHORTMODNAME</makevar></entry>
|
|
<entry>Short name of the module. Automatically
|
|
derived from <makevar>MODULENAME</makevar>, but can
|
|
be overridden. Example:
|
|
<literal>hello</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>AP_FAST_BUILD</makevar></entry>
|
|
<entry>Use <command>apxs</command> to compile and
|
|
install the module.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>AP_GENPLIST</makevar></entry>
|
|
<entry>Also automatically creates a
|
|
<filename>pkg-plist</filename>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>AP_INC</makevar></entry>
|
|
<entry>Adds a directory to a header search path during
|
|
compilation.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>AP_LIB</makevar></entry>
|
|
<entry>Adds a directory to a library search path
|
|
during compilation.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>AP_EXTRAS</makevar></entry>
|
|
<entry>Additional flags to pass to
|
|
<command>apxs</command>.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2 id="web-apps">
|
|
<title>Web Applications</title>
|
|
|
|
<para>Web applications should be installed into
|
|
<filename><makevar>PREFIX</makevar>/www/<replaceable>appname</replaceable></filename>.
|
|
For your convenience, this path is available both in
|
|
<filename>Makefile</filename> and in
|
|
<filename>pkg-plist</filename> as <makevar>WWWDIR</makevar>,
|
|
and the path relative to <makevar>PREFIX</makevar> is
|
|
available in <filename>Makefile</filename> as
|
|
<makevar>WWWDIR_REL</makevar>.</para>
|
|
|
|
<para>The user and group of web server process are available
|
|
as <makevar>WWWOWN</makevar> and <makevar>WWWGRP</makevar>,
|
|
in case you need to change the ownership of some files. The
|
|
default values of both are <literal>www</literal>. If you
|
|
want different values for your port, use <literal>WWWOWN?=
|
|
myuser</literal> notation, to allow user to override it
|
|
easily.</para>
|
|
|
|
<para>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.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="php-variables">
|
|
<title>PHP</title>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use PHP</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_PHP</makevar></entry>
|
|
<entry>The port requires PHP. The value
|
|
<literal>yes</literal> adds a dependency on PHP.
|
|
The list of required PHP extensions can be specified
|
|
instead. Example: <literal>pcre xml
|
|
gettext</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>DEFAULT_PHP_VER</makevar></entry>
|
|
<entry>Selects which major version of PHP will be
|
|
installed as a dependency when no PHP is installed
|
|
yet. Default is <literal>5</literal>. Possible
|
|
values: <literal>4</literal>,
|
|
<literal>5</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>IGNORE_WITH_PHP</makevar></entry>
|
|
<entry>The port does not work with PHP of the given
|
|
version. Possible values: <literal>4</literal>,
|
|
<literal>5</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_PHPIZE</makevar></entry>
|
|
<entry>The port will be built as a PHP
|
|
extension.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_PHPEXT</makevar></entry>
|
|
<entry>The port will be treated as a PHP extension,
|
|
including installation and registration in the
|
|
extension registry.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_PHP_BUILD</makevar></entry>
|
|
<entry>Set PHP as a build dependency.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WANT_PHP_CLI</makevar></entry>
|
|
<entry>Want the CLI (command line) version of
|
|
PHP.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WANT_PHP_CGI</makevar></entry>
|
|
<entry>Want the CGI version of PHP.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WANT_PHP_MOD</makevar></entry>
|
|
<entry>Want the Apache module version of PHP.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WANT_PHP_SCR</makevar></entry>
|
|
<entry>Want the CLI or the CGI version of PHP.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WANT_PHP_WEB</makevar></entry>
|
|
<entry>Want the Apache module or the CGI version of
|
|
PHP.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>PEAR Modules</title>
|
|
|
|
<para>Porting PEAR modules is a very simple process.</para>
|
|
|
|
<para>Use the variables <makevar>FILES</makevar>,
|
|
<makevar>TESTS</makevar>, <makevar>DATA</makevar>,
|
|
<makevar>SQLS</makevar>, <makevar>SCRIPTFILES</makevar>,
|
|
<makevar>DOCS</makevar> and <makevar>EXAMPLES</makevar> to
|
|
list the files you want to install. All listed files will
|
|
be automatically installed into the appropriate locations
|
|
and added to <filename>pkg-plist</filename>.</para>
|
|
|
|
<para>Include
|
|
<filename>${PORTSDIR}/devel/pear/bsd.pear.mk</filename>
|
|
on the last line of the
|
|
<filename>Makefile</filename>.</para>
|
|
|
|
<example id="pear-makefile">
|
|
<title>Example Makefile for PEAR Class</title>
|
|
|
|
<programlisting>PORTNAME= Date
|
|
PORTVERSION= 1.4.3
|
|
CATEGORIES= devel www pear
|
|
|
|
MAINTAINER= example@domain.com
|
|
COMMENT= PEAR Date and Time Zone Classes
|
|
|
|
BUILD_DEPENDS= ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR
|
|
RUN_DEPENDS:= ${BUILD_DEPENDS}
|
|
|
|
FILES= Date.php Date/Calc.php Date/Human.php Date/Span.php \
|
|
Date/TimeZone.php
|
|
TESTS= test_calc.php test_date_methods_span.php testunit.php \
|
|
testunit_date.php testunit_date_span.php wknotest.txt \
|
|
bug674.php bug727_1.php bug727_2.php bug727_3.php \
|
|
bug727_4.php bug967.php weeksinmonth_4_monday.txt \
|
|
weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt \
|
|
weeksinmonth_rdm_sunday.txt
|
|
DOCS= TODO
|
|
_DOCSDIR= .
|
|
|
|
.include <bsd.port.pre.mk>
|
|
.include "${PORTSDIR}/devel/pear/bsd.pear.mk"
|
|
.include <bsd.port.post.mk></programlisting>
|
|
</example>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-python">
|
|
<title>Using Python</title>
|
|
|
|
<para>The Ports Collection supports parallel installation of
|
|
multiple Python versions. Ports should make sure to use a
|
|
correct <command>python</command> interpreter, according to
|
|
the user-settable <makevar>PYTHON_VERSION</makevar> variable.
|
|
Most prominently, this means replacing the path to
|
|
<command>python</command> executable in scripts with the value
|
|
of <makevar>PYTHON_CMD</makevar> variable.</para>
|
|
|
|
<para>Ports that install files under
|
|
<makevar>PYTHON_SITELIBDIR</makevar> should use the
|
|
<literal>pyXY-</literal> package name prefix, so their package
|
|
name embeds the version of Python they are installed
|
|
into.</para>
|
|
|
|
<programlisting>PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}</programlisting>
|
|
|
|
<table frame="none">
|
|
<title>Most Useful Variables for Ports That Use Python</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_PYTHON</makevar></entry>
|
|
<entry>The port needs Python. Minimal required version
|
|
can be specified with values such as
|
|
<literal>2.6+</literal>. Version ranges can also be
|
|
specified, by separating two version numbers with a
|
|
dash, e.g.: <literal>2.6-2.7</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_PYDISTUTILS</makevar></entry>
|
|
<entry>Use Python distutils for configuring, compiling
|
|
and installing. This is required when the port comes
|
|
with <filename>setup.py</filename>. This overrides
|
|
the <maketarget>do-build</maketarget> and
|
|
<maketarget>do-install</maketarget> targets and may
|
|
also override <maketarget>do-configure</maketarget> if
|
|
<makevar>GNU_CONFIGURE</makevar> is not
|
|
defined.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYTHON_PKGNAMEPREFIX</makevar></entry>
|
|
<entry>Used as a <makevar>PKGNAMEPREFIX</makevar> to
|
|
distinguish packages for different Python versions.
|
|
Example: <literal>py24-</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYTHON_SITELIBDIR</makevar></entry>
|
|
<entry>Location of the site-packages tree, that contains
|
|
installation path of Python (usually
|
|
<makevar>LOCALBASE</makevar>). The
|
|
<makevar>PYTHON_SITELIBDIR</makevar> variable can be
|
|
very useful when installing Python modules.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYTHONPREFIX_SITELIBDIR</makevar></entry>
|
|
<entry>The PREFIX-clean variant of PYTHON_SITELIBDIR.
|
|
Always use <literal>%%PYTHON_SITELIBDIR%%</literal> in
|
|
<filename>pkg-plist</filename> when possible. The
|
|
default value of
|
|
<literal>%%PYTHON_SITELIBDIR%%</literal> is
|
|
<literal>lib/python%%PYTHON_VERSION%%/site-packages</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYTHON_CMD</makevar></entry>
|
|
<entry>Python interpreter command line, including
|
|
version number.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYNUMERIC</makevar></entry>
|
|
<entry>Dependency line for numeric extension.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYNUMPY</makevar></entry>
|
|
<entry>Dependency line for the new numeric extension,
|
|
numpy. (PYNUMERIC is deprecated by upstream
|
|
vendor).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PYXML</makevar></entry>
|
|
<entry>Dependency line for XML extension (not needed for
|
|
Python 2.0 and higher as it is also in base
|
|
distribution).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_TWISTED</makevar></entry>
|
|
<entry>Add dependency on twistedCore. The list of
|
|
required components can be specified as a value of
|
|
this variable. Example: <literal>web lore pair
|
|
flow</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_ZOPE</makevar></entry>
|
|
<entry>Add dependency on Zope, a web application
|
|
platform. Change Python dependency to Python 2.7.
|
|
Set <makevar>ZOPEBASEDIR</makevar> containing a
|
|
directory with Zope installation.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>A complete list of available variables can be found in
|
|
<filename>/usr/ports/Mk/bsd.python.mk</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="using-tcl">
|
|
<title>Using <application>Tcl/Tk</application></title>
|
|
|
|
<para>The Ports Collection supports parallel installation of
|
|
multiple <application>Tcl/Tk</application> versions. Ports
|
|
should try to support at least the default
|
|
<application>Tcl/Tk</application> version and higher with the
|
|
<makevar>USE_TCL</makevar> and <makevar>USE_TK</makevar>
|
|
variables. It is possible to specify the desired version of
|
|
<command>tcl</command> with the
|
|
<makevar>WITH_TCL_VER</makevar> variable.</para>
|
|
|
|
<table frame="none">
|
|
<title>The Most Useful Variables for Ports That Use
|
|
<application>Tcl/Tk</application></title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_TCL</makevar></entry>
|
|
<entry>The port depends on the
|
|
<application>Tcl</application> library (not the
|
|
shell). Minimal required version can be specified
|
|
with values such as 84+. Individual unsupported
|
|
versions can be specified with the
|
|
<makevar>INVALID_TCL_VER</makevar> variable.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_TCL_BUILD</makevar></entry>
|
|
<entry>The port needs <application>Tcl</application>
|
|
only during the build time.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_TCL_WRAPPER</makevar></entry>
|
|
<entry>Ports that require the
|
|
<application>Tcl</application> shell and do not
|
|
require a specific <literal>tclsh</literal> version
|
|
should use this new variable. The
|
|
<literal>tclsh</literal> wrapper is installed on the
|
|
system. The user can specify the desired
|
|
<command>tcl</command> shell to use.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_TCL_VER</makevar></entry>
|
|
<entry>User-defined variable that sets the desired
|
|
<application>Tcl</application> version.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar><replaceable>UNIQUENAME</replaceable>_WITH_TCL_VER</makevar></entry>
|
|
<entry>Like <makevar>WITH_TCL_VER</makevar>, but
|
|
per-port.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_TCL_THREADS</makevar></entry>
|
|
<entry>Require a threaded build of
|
|
<application>Tcl/Tk</application>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_TK</makevar></entry>
|
|
<entry>The port depends on the
|
|
<application>Tk</application> library (not the wish
|
|
shell). Implies <makevar>USE_TCL</makevar> with the
|
|
same value. For more information see the description
|
|
of <makevar>USE_TCL</makevar> variable.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_TK_BUILD</makevar></entry>
|
|
<entry>Analog to the <makevar>USE_TCL_BUILD</makevar>
|
|
variable.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_TK_WRAPPER</makevar></entry>
|
|
<entry>Analog to the <makevar>USE_TCL_WRAPPER</makevar>
|
|
variable.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_TK_VER</makevar></entry>
|
|
<entry>Analog to the <makevar>WITH_TCL_VER</makevar>
|
|
variable and implies <makevar>WITH_TCL_VER</makevar>
|
|
of the same value.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>A complete list of available variables can be found in
|
|
<filename>/usr/ports/Mk/bsd.tcl.mk</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="using-emacs">
|
|
<title>Using Emacs</title>
|
|
|
|
<para>This section is yet to be written.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="using-ruby">
|
|
<title>Using Ruby</title>
|
|
|
|
<table frame="none">
|
|
<title>Useful Variables for Ports That Use Ruby</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_RUBY</makevar></entry>
|
|
<entry>The port requires Ruby.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_RUBY_EXTCONF</makevar></entry>
|
|
<entry>The port uses <filename>extconf.rb</filename> to
|
|
configure.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_RUBY_SETUP</makevar></entry>
|
|
<entry>The port uses <filename>setup.rb</filename> to
|
|
configure.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RUBY_SETUP</makevar></entry>
|
|
<entry>Set to the alternative name of
|
|
<filename>setup.rb</filename>. Common value is
|
|
<filename>install.rb</filename>.</entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>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 <filename>pkg-plist</filename> as much as
|
|
possible. These variables should not be redefined in the
|
|
port.</para>
|
|
|
|
<table frame="none">
|
|
<title>Selected Read-Only Variables for Ports That Use
|
|
Ruby</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Description</entry>
|
|
<entry>Example value</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry><makevar>RUBY_PKGNAMEPREFIX</makevar></entry>
|
|
<entry>Used as a <makevar>PKGNAMEPREFIX</makevar> to
|
|
distinguish packages for different Ruby
|
|
versions.</entry>
|
|
<entry><literal>ruby18-</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RUBY_VERSION</makevar></entry>
|
|
<entry>Full version of Ruby in the form of
|
|
<literal>x.y.z</literal>.</entry>
|
|
<entry><literal>1.8.2</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RUBY_SITELIBDIR</makevar></entry>
|
|
<entry>Architecture independent libraries installation
|
|
path.</entry>
|
|
<entry><literal>/usr/local/lib/ruby/site_ruby/1.8</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RUBY_SITEARCHLIBDIR</makevar></entry>
|
|
<entry>Architecture dependent libraries installation
|
|
path.</entry>
|
|
<entry><literal>/usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RUBY_MODDOCDIR</makevar></entry>
|
|
<entry>Module documentation installation path.</entry>
|
|
<entry><literal>/usr/local/share/doc/ruby18/patsy</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>RUBY_MODEXAMPLESDIR</makevar></entry>
|
|
<entry>Module examples installation path.</entry>
|
|
<entry><literal>/usr/local/share/examples/ruby18/patsy</literal></entry>
|
|
</row>
|
|
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>A complete list of available variables can be found in
|
|
<filename>/usr/ports/Mk/bsd.ruby.mk</filename>.</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="using-sdl">
|
|
<title>Using SDL</title>
|
|
|
|
<para>The <makevar>USE_SDL</makevar> variable is used to
|
|
autoconfigure the dependencies for ports which use an SDL
|
|
based library like <filename
|
|
role="package">devel/sdl12</filename> and <filename
|
|
role="package">x11-toolkits/sdl_gui</filename>.</para>
|
|
|
|
<para>The following SDL libraries are recognized at the
|
|
moment:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>sdl: <filename
|
|
role="package">devel/sdl12</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>gfx: <filename
|
|
role="package">graphics/sdl_gfx</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>gui: <filename
|
|
role="package">x11-toolkits/sdl_gui</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>image: <filename
|
|
role="package">graphics/sdl_image</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ldbad: <filename
|
|
role="package">devel/sdl_ldbad</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>mixer: <filename
|
|
role="package">audio/sdl_mixer</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>mm: <filename
|
|
role="package">devel/sdlmm</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>net: <filename
|
|
role="package">net/sdl_net</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>sound: <filename
|
|
role="package">audio/sdl_sound</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ttf: <filename
|
|
role="package">graphics/sdl_ttf</filename></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Therefore, if a port has a dependency on
|
|
<filename role="package">net/sdl_net</filename> and
|
|
<filename role="package">audio/sdl_mixer</filename>,
|
|
the syntax will be:</para>
|
|
|
|
<programlisting>USE_SDL= net mixer</programlisting>
|
|
|
|
<para>The dependency <filename
|
|
role="package">devel/sdl12</filename>, which is required by
|
|
<filename role="package">net/sdl_net</filename> and <filename
|
|
role="package">audio/sdl_mixer</filename>, is automatically
|
|
added as well.</para>
|
|
|
|
<para>If you use <makevar>USE_SDL</makevar>, it will
|
|
automatically:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Add a dependency on
|
|
<application>sdl12-config</application> to
|
|
<makevar>BUILD_DEPENDS</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Add the variable <makevar>SDL_CONFIG</makevar> to
|
|
<makevar>CONFIGURE_ENV</makevar></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Add the dependencies of the selected libraries to the
|
|
<makevar>LIB_DEPENDS</makevar></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>To check whether an SDL library is available, you can do
|
|
it with the <makevar>WANT_SDL</makevar> variable:</para>
|
|
|
|
<programlisting>WANT_SDL= yes
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if ${HAVE_SDL:Mmixer}!=""
|
|
USE_SDL+= mixer
|
|
.endif
|
|
|
|
.include <bsd.port.post.mk></programlisting>
|
|
</sect1>
|
|
|
|
<sect1 id="using-wx">
|
|
<title>Using <application>wxWidgets</application></title>
|
|
|
|
<para>This section describes the status of the
|
|
<application>wxWidgets</application> libraries in the ports
|
|
tree and its integration with the ports system.</para>
|
|
|
|
<sect2 id="wx-introduction">
|
|
<title>Introduction</title>
|
|
|
|
<para>There are many versions of the
|
|
<application>wxWidgets</application> 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.</para>
|
|
|
|
<para>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
|
|
<command>wx-config</command> 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
|
|
<command>wx-config</command> script to call. Otherwise they
|
|
have to be patched.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="wx-version">
|
|
<title>Version Selection</title>
|
|
|
|
<para>To make your port use a specific version of
|
|
<application>wxWidgets</application> there are two variables
|
|
available for defining (if only one is defined the other
|
|
will be set to a default value):</para>
|
|
|
|
<table id="wx-ver-sel-table" frame="none">
|
|
<title>Variables to Select
|
|
<application>wxWidgets</application> Versions</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Description</entry>
|
|
<entry>Default value</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_WX</makevar></entry>
|
|
<entry>List of versions the port can use</entry>
|
|
<entry>All available versions</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_WX_NOT</makevar></entry>
|
|
<entry>List of versions the port can not use</entry>
|
|
<entry>None</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>The following is a list of available
|
|
<application>wxWidgets</application> versions and the
|
|
corresponding ports in the tree:</para>
|
|
|
|
<table frame="none">
|
|
<title>Available <application>wxWidgets</application>
|
|
Versions</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Version</entry>
|
|
<entry>Port</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>2.4</literal></entry>
|
|
<entry><filename
|
|
role="package">x11-toolkits/wxgtk24</filename></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>2.6</literal></entry>
|
|
<entry><filename
|
|
role="package">x11-toolkits/wxgtk26</filename></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>2.8</literal></entry>
|
|
<entry><filename
|
|
role="package">x11-toolkits/wxgtk28</filename></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<note>
|
|
<para>The versions starting from <literal>2.5</literal> also
|
|
come in Unicode version and are installed by a slave port
|
|
named like the normal one plus a
|
|
<literal>-unicode</literal> suffix, but this can be
|
|
handled with variables (see <xref
|
|
linkend="wx-unicode"/>).</para>
|
|
</note>
|
|
|
|
<para>The variables in <xref linkend="wx-ver-sel-table"/> can
|
|
be set to one or more of the following combinations
|
|
separated by spaces:</para>
|
|
|
|
<table frame="none">
|
|
<title><application>wxWidgets</application> Version
|
|
Specifications</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Description</entry>
|
|
<entry>Example</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>Single version</entry>
|
|
<entry><literal>2.4</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Ascending range</entry>
|
|
<entry><literal>2.4+</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Descending range</entry>
|
|
<entry><literal>2.6-</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Full range (must be ascending)</entry>
|
|
<entry><literal>2.4-2.6</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>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.</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables to Select Preferred
|
|
<application>wxWidgets</application> Versions</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Designed for</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>WANT_WX_VER</makevar></entry>
|
|
<entry>the port</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_WX_VER</makevar></entry>
|
|
<entry>the user</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2 id="wx-components">
|
|
<title>Component Selection</title>
|
|
|
|
<para>There are other applications that, while not being
|
|
<application>wxWidgets</application> libraries, are related
|
|
to them. These applications can be specified in the
|
|
<makevar>WX_COMPS</makevar> variable. The following
|
|
components are available:</para>
|
|
|
|
<table frame="none">
|
|
<title>Available <application>wxWidgets</application>
|
|
Components</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
<entry>Version restriction</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>wx</literal></entry>
|
|
<entry>main library</entry>
|
|
<entry>none</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>contrib</literal></entry>
|
|
<entry>contributed libraries</entry>
|
|
<entry><literal>none</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>python</literal></entry>
|
|
<entry><application>wxPython</application>
|
|
(<application>Python</application> bindings)</entry>
|
|
<entry><literal>2.4-2.6</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>mozilla</literal></entry>
|
|
<entry><application>wxMozilla</application></entry>
|
|
<entry><literal>2.4</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>svg</literal></entry>
|
|
<entry><application>wxSVG</application></entry>
|
|
<entry><literal>2.6</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>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 <xref
|
|
linkend="wx-def-dep-types"/>). The following types are
|
|
available:</para>
|
|
|
|
<table frame="none">
|
|
<title>Available <application>wxWidgets</application>
|
|
Dependency Types</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>build</literal></entry>
|
|
<entry>Component is required for building, equivalent
|
|
to <makevar>BUILD_DEPENDS</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>run</literal></entry>
|
|
<entry>Component is required for running, equivalent
|
|
to <makevar>RUN_DEPENDS</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>lib</literal></entry>
|
|
<entry>Component is required for building and running,
|
|
equivalent to <makevar>LIB_DEPENDS</makevar></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>The default values for the components are detailed in
|
|
the following table:</para>
|
|
|
|
<table id="wx-def-dep-types" frame="none">
|
|
<title>Default <application>wxWidgets</application>
|
|
Dependency Types</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Component</entry>
|
|
<entry>Dependency type</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>wx</literal></entry>
|
|
<entry><literal>lib</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>contrib</literal></entry>
|
|
<entry><literal>lib</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>python</literal></entry>
|
|
<entry><literal>run</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>mozilla</literal></entry>
|
|
<entry><literal>lib</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>svg</literal></entry>
|
|
<entry><literal>lib</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<example id="wx-components-example">
|
|
<title>Selecting <application>wxWidgets</application>
|
|
Components</title>
|
|
|
|
<para>The following fragment corresponds to a port which
|
|
uses <application>wxWidgets</application> version
|
|
<literal>2.4</literal> and its contributed
|
|
libraries.</para>
|
|
|
|
<programlisting>USE_WX= 2.4
|
|
WX_COMPS= wx contrib</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="wx-unicode">
|
|
<title>Unicode</title>
|
|
|
|
<para>The <application>wxWidgets</application> library
|
|
supports Unicode since version <literal>2.5</literal>. In
|
|
the ports tree both versions are available and can be
|
|
selected with the following variables:</para>
|
|
|
|
<table id="wx-unicode-var-table" frame="none">
|
|
<title>Variables to Select Unicode in
|
|
<application>wxWidgets</application>
|
|
Versions</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Description</entry>
|
|
<entry>Designed for</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>WX_UNICODE</makevar></entry>
|
|
<entry>The port works <emphasis>only</emphasis> with
|
|
the Unicode version</entry>
|
|
<entry>the port</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WANT_UNICODE</makevar></entry>
|
|
<entry>The port works with both versions but prefers
|
|
the Unicode one</entry>
|
|
<entry>the port</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_UNICODE</makevar></entry>
|
|
<entry>The port will use the Unicode version</entry>
|
|
<entry>the user</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITHOUT_UNICODE</makevar></entry>
|
|
<entry>The port will use the normal version if
|
|
supported (when <makevar>WX_UNICODE</makevar> is not
|
|
defined)</entry>
|
|
<entry>the user</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<warning>
|
|
<para>Do not use <makevar>WX_UNICODE</makevar> for ports
|
|
that can use both Unicode and normal versions. If you
|
|
want the port to use Unicode by default define
|
|
<makevar>WANT_UNICODE</makevar> instead.</para>
|
|
</warning>
|
|
</sect2>
|
|
|
|
<sect2 id="wx-version-detection">
|
|
<title>Detecting Installed Versions</title>
|
|
|
|
<para>To detect an installed version you have to define
|
|
<makevar>WANT_WX</makevar>. If you do not set it to a
|
|
specific version then the components will have a version
|
|
suffix. The <makevar>HAVE_WX</makevar> variable will be
|
|
filled after detection.</para>
|
|
|
|
<example id="wx-ver-det-example">
|
|
<title>Detecting Installed
|
|
<application>wxWidgets</application> Versions and
|
|
Components</title>
|
|
|
|
<para>The following fragment can be used in a port that uses
|
|
<application>wxWidgets</application> if it is installed,
|
|
or an option is selected.</para>
|
|
|
|
<programlisting>WANT_WX= yes
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.4)
|
|
USE_WX= 2.4
|
|
CONFIGURE_ARGS+= --enable-wx
|
|
.endif</programlisting>
|
|
|
|
<para>The following fragment can be used in a port that
|
|
enables <application>wxPython</application> support if it
|
|
is installed or if an option is selected, in addition to
|
|
<application>wxWidgets</application>, both version
|
|
<literal>2.6</literal>.</para>
|
|
|
|
<programlisting>USE_WX= 2.6
|
|
WX_COMPS= wx
|
|
WANT_WX= 2.6
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if defined(WITH_WXPYTHON) || !empty(PORT_OPTIONS:MWXPYTHON) || !empty(HAVE_WX:Mpython)
|
|
WX_COMPS+= python
|
|
CONFIGURE_ARGS+= --enable-wxpython
|
|
.endif</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="wx-defined-variables">
|
|
<title>Defined Variables</title>
|
|
|
|
<para>The following variables are available in the port (after
|
|
defining one from <xref linkend="wx-ver-sel-table"/>).</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables Defined for Ports That Use
|
|
<application>wxWidgets</application></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>WX_CONFIG</makevar></entry>
|
|
<entry>The path to the
|
|
<application>wxWidgets</application>
|
|
<command>wx-config</command> script (with different
|
|
name)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WXRC_CMD</makevar></entry>
|
|
<entry>The path to the
|
|
<application>wxWidgets</application>
|
|
<command>wxrc</command> program (with different
|
|
name)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WX_VERSION</makevar></entry>
|
|
<entry>The <application>wxWidgets</application>
|
|
version that is going to be used (e.g.,
|
|
<literal>2.6</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WX_UNICODE</makevar></entry>
|
|
<entry>If not defined but Unicode is going to be used
|
|
then it will be defined</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2 id="wx-premk">
|
|
<title>Processing in
|
|
<filename>bsd.port.pre.mk</filename></title>
|
|
|
|
<para>If you need to use the variables for running commands
|
|
right after including <filename>bsd.port.pre.mk</filename>
|
|
you need to define <makevar>WX_PREMK</makevar>.</para>
|
|
|
|
<important>
|
|
<para>If you define <makevar>WX_PREMK</makevar>, then the
|
|
version, dependencies, components and defined variables
|
|
will not change if you modify the
|
|
<application>wxWidgets</application> port variables
|
|
<emphasis>after</emphasis> including
|
|
<filename>bsd.port.pre.mk</filename>.</para>
|
|
</important>
|
|
|
|
<example id="wx-premk-example">
|
|
<title>Using <application>wxWidgets</application> Variables
|
|
in Commands</title>
|
|
|
|
<para>The following fragment illustrates the use of
|
|
<makevar>WX_PREMK</makevar> by running the
|
|
<command>wx-config</command> script to obtain the full
|
|
version string, assign it to a variable and pass it to the
|
|
program.</para>
|
|
|
|
<programlisting>USE_WX= 2.4
|
|
WX_PREMK= yes
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if exists(${WX_CONFIG})
|
|
VER_STR!= ${WX_CONFIG} --release
|
|
|
|
PLIST_SUB+= VERSION="${VER_STR}"
|
|
.endif</programlisting>
|
|
</example>
|
|
|
|
<note>
|
|
<para>The <application>wxWidgets</application> variables can
|
|
be safely used in commands when they are inside targets
|
|
without the need of <makevar>WX_PREMK</makevar>.</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 id="wx-additional-config-args">
|
|
<title>Additional <command>configure</command>
|
|
Arguments</title>
|
|
|
|
<para>Some GNU <command>configure</command> scripts can not
|
|
find <application>wxWidgets</application> with just the
|
|
<literal>WX_CONFIG</literal> environment variable set,
|
|
requiring additional arguments. The
|
|
<makevar>WX_CONF_ARGS</makevar> variable can be used for
|
|
provide them.</para>
|
|
|
|
<table frame="none">
|
|
<title>Legal Values for
|
|
<makevar>WX_CONF_ARGS</makevar></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Possible value</entry>
|
|
<entry>Resulting argument</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>absolute</literal></entry>
|
|
<entry><literal>--with-wx-config=${WX_CONFIG}</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>relative</literal></entry>
|
|
<entry><literal>--with-wx=${LOCALBASE}
|
|
--with-wx-config=${WX_CONFIG:T}</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-lua">
|
|
<title>Using <application>Lua</application></title>
|
|
|
|
<para>This section describes the status of the
|
|
<application>Lua</application> libraries in the ports tree and
|
|
its integration with the ports system.</para>
|
|
|
|
<sect2 id="lua-introduction">
|
|
<title>Introduction</title>
|
|
|
|
<para>There are many versions of the
|
|
<application>Lua</application> 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.</para>
|
|
|
|
<para>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.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="lua-version">
|
|
<title>Version Selection</title>
|
|
|
|
<para>To make your port use a specific version of
|
|
<application>Lua</application> there are two variables
|
|
available for defining (if only one is defined the other
|
|
will be set to a default value):</para>
|
|
|
|
<table id="lua-ver-sel-table" frame="none">
|
|
<title>Variables to Select <application>Lua</application>
|
|
Versions</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Description</entry>
|
|
<entry>Default value</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_LUA</makevar></entry>
|
|
<entry>List of versions the port can use</entry>
|
|
<entry>All available versions</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_LUA_NOT</makevar></entry>
|
|
<entry>List of versions the port can not use</entry>
|
|
<entry>None</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>The following is a list of available
|
|
<application>Lua</application> versions and the
|
|
corresponding ports in the tree:</para>
|
|
|
|
<table frame="none">
|
|
<title>Available <application>Lua</application>
|
|
Versions</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Version</entry>
|
|
<entry>Port</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>4.0</literal></entry>
|
|
<entry><filename
|
|
role="package">lang/lua4</filename></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>5.0</literal></entry>
|
|
<entry><filename
|
|
role="package">lang/lua50</filename></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>5.1</literal></entry>
|
|
<entry><filename
|
|
role="package">lang/lua</filename></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>The variables in <xref linkend="lua-ver-sel-table"/> can
|
|
be set to one or more of the following combinations
|
|
separated by spaces:</para>
|
|
|
|
<table frame="none">
|
|
<title><application>Lua</application> Version
|
|
Specifications</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Description</entry>
|
|
<entry>Example</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>Single version</entry>
|
|
<entry><literal>4.0</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Ascending range</entry>
|
|
<entry><literal>5.0+</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Descending range</entry>
|
|
<entry><literal>5.0-</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Full range (must be ascending)</entry>
|
|
<entry><literal>5.0-5.1</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>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.</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables to Select Preferred
|
|
<application>Lua</application> Versions</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Designed for</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>WANT_LUA_VER</makevar></entry>
|
|
<entry>the port</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>WITH_LUA_VER</makevar></entry>
|
|
<entry>the user</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<example id="lua-version-example">
|
|
<title>Selecting the <application>Lua</application>
|
|
Version</title>
|
|
|
|
<para>The following fragment is from a port which can use
|
|
<application>Lua</application> version
|
|
<literal>5.0</literal> or <literal>5.1</literal>, and uses
|
|
<literal>5.0</literal> by default. It can be overridden
|
|
by the user with <makevar>WITH_LUA_VER</makevar>.</para>
|
|
|
|
<programlisting>USE_LUA= 5.0-5.1
|
|
WANT_LUA_VER= 5.0</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="lua-components">
|
|
<title>Component Selection</title>
|
|
|
|
<para>There are other applications that, while not being
|
|
<application>Lua</application> libraries, are related to
|
|
them. These applications can be specified in the
|
|
<makevar>LUA_COMPS</makevar> variable. The following
|
|
components are available:</para>
|
|
|
|
<table frame="none">
|
|
<title>Available <application>Lua</application>
|
|
Components</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
<entry>Version restriction</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>lua</literal></entry>
|
|
<entry>main library</entry>
|
|
<entry>none</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>tolua</literal></entry>
|
|
<entry>Library for accessing C/C++ code</entry>
|
|
<entry><literal>4.0-5.0</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>ruby</literal></entry>
|
|
<entry>Ruby bindings</entry>
|
|
<entry><literal>4.0-5.0</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<note>
|
|
<para>There are more components but they are modules for the
|
|
interpreter, not used by applications (only by other
|
|
modules).</para>
|
|
</note>
|
|
|
|
<para>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 <xref
|
|
linkend="lua-def-dep-types"/>). The following types are
|
|
available:</para>
|
|
|
|
<table frame="none">
|
|
<title>Available <application>Lua</application> Dependency
|
|
Types</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>build</literal></entry>
|
|
<entry>Component is required for building, equivalent
|
|
to <makevar>BUILD_DEPENDS</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>run</literal></entry>
|
|
<entry>Component is required for running, equivalent
|
|
to <makevar>RUN_DEPENDS</makevar></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>lib</literal></entry>
|
|
<entry>Component is required for building and running,
|
|
equivalent to <makevar>LIB_DEPENDS</makevar></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>The default values for the components are detailed in
|
|
the following table:</para>
|
|
|
|
<table id="lua-def-dep-types" frame="none">
|
|
<title>Default <application>Lua</application> Dependency
|
|
Types</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Component</entry>
|
|
<entry>Dependency type</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>lua</literal></entry>
|
|
<entry><literal>lib</literal> for
|
|
<literal>4.0-5.0</literal> (shared) and
|
|
<literal>build</literal> for <literal>5.1</literal>
|
|
(static)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>tolua</literal></entry>
|
|
<entry><literal>build</literal> (static)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>ruby</literal></entry>
|
|
<entry><literal>lib</literal> (shared)</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<example id="lua-components-example">
|
|
<title>Selecting <application>Lua</application>
|
|
Components</title>
|
|
|
|
<para>The following fragment corresponds to a port which
|
|
uses <application>Lua</application> version
|
|
<literal>4.0</literal> and its
|
|
<application>Ruby</application> bindings.</para>
|
|
|
|
<programlisting>USE_LUA= 4.0
|
|
LUA_COMPS= lua ruby</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="lua-version-detection">
|
|
<title>Detecting Installed Versions</title>
|
|
|
|
<para>To detect an installed version you have to define
|
|
<makevar>WANT_LUA</makevar>. If you do not set it to a
|
|
specific version then the components will have a version
|
|
suffix. The <makevar>HAVE_LUA</makevar> variable will be
|
|
filled after detection.</para>
|
|
|
|
<example id="lua-ver-det-example">
|
|
<title>Detecting Installed <application>Lua</application>
|
|
Versions and Components</title>
|
|
|
|
<para>The following fragment can be used in a port that uses
|
|
<application>Lua</application> if it is installed, or an
|
|
option is selected.</para>
|
|
|
|
<programlisting>WANT_LUA= yes
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if defined(WITH_LUA5) || !empty(PORT_OPTIONS:MLUA5) || !empty(HAVE_LUA:Mlua-5.[01])
|
|
USE_LUA= 5.0-5.1
|
|
CONFIGURE_ARGS+= --enable-lua5
|
|
.endif</programlisting>
|
|
|
|
<para>The following fragment can be used in a port that
|
|
enables <application>tolua</application> support if it is
|
|
installed or if an option is selected, in addition to
|
|
<application>Lua</application>, both version
|
|
<literal>4.0</literal>.</para>
|
|
|
|
<programlisting>USE_LUA= 4.0
|
|
LUA_COMPS= lua
|
|
WANT_LUA= 4.0
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if defined(WITH_TOLUA) || !empty(PORT_OPTIONS:MTOLUA) || !empty(HAVE_LUA:Mtolua)
|
|
LUA_COMPS+= tolua
|
|
CONFIGURE_ARGS+= --enable-tolua
|
|
.endif</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="lua-defined-variables">
|
|
<title>Defined Variables</title>
|
|
|
|
<para>The following variables are available in the port (after
|
|
defining one from <xref
|
|
linkend="lua-ver-sel-table"/>).</para>
|
|
|
|
<table frame="none">
|
|
<title>Variables Defined for Ports That Use
|
|
<application>Lua</application></title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>LUA_VER</makevar></entry>
|
|
<entry>The <application>Lua</application> version that
|
|
is going to be used (e.g.,
|
|
<literal>5.1</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_VER_SH</makevar></entry>
|
|
<entry>The <application>Lua</application> shared
|
|
library major version (e.g.,
|
|
<literal>1</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_VER_STR</makevar></entry>
|
|
<entry>The <application>Lua</application> version
|
|
without the dots (e.g.,
|
|
<literal>51</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_PREFIX</makevar></entry>
|
|
<entry>The prefix where <application>Lua</application>
|
|
(and components) is installed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_SUBDIR</makevar></entry>
|
|
<entry>The directory under
|
|
<filename>${PREFIX}/bin</filename>,
|
|
<filename>${PREFIX}/share</filename> and
|
|
<filename>${PREFIX}/lib</filename> where
|
|
<application>Lua</application> is installed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_INCDIR</makevar></entry>
|
|
<entry>The directory where
|
|
<application>Lua</application> and
|
|
<application>tolua</application> header files are
|
|
installed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_LIBDIR</makevar></entry>
|
|
<entry>The directory where
|
|
<application>Lua</application> and
|
|
<application>tolua</application> libraries are
|
|
installed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_MODLIBDIR</makevar></entry>
|
|
<entry>The directory where
|
|
<application>Lua</application> module libraries
|
|
(<filename>.so</filename>) are installed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_MODSHAREDIR</makevar></entry>
|
|
<entry>The directory where
|
|
<application>Lua</application> modules
|
|
(<filename>.lua</filename>) are installed</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_PKGNAMEPREFIX</makevar></entry>
|
|
<entry>The package name prefix used by
|
|
<application>Lua</application> modules</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUA_CMD</makevar></entry>
|
|
<entry>The path to the <application>Lua</application>
|
|
interpreter</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LUAC_CMD</makevar></entry>
|
|
<entry>The path to the <application>Lua</application>
|
|
compiler</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>TOLUA_CMD</makevar></entry>
|
|
<entry>The path to the
|
|
<application>tolua</application> program</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<example id="lua-variables-example">
|
|
<title>Telling the Port Where to Find
|
|
<application>Lua</application></title>
|
|
|
|
<para>The following fragment shows how to tell a port that
|
|
uses a configure script where the
|
|
<application>Lua</application> header files and libraries
|
|
are.</para>
|
|
|
|
<programlisting>USE_LUA= 4.0
|
|
GNU_CONFIGURE= yes
|
|
CONFIGURE_ENV= CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"</programlisting>
|
|
</example>
|
|
</sect2>
|
|
|
|
<sect2 id="lua-premk">
|
|
<title>Processing in
|
|
<filename>bsd.port.pre.mk</filename></title>
|
|
|
|
<para>If you need to use the variables for running commands
|
|
right after including <filename>bsd.port.pre.mk</filename>
|
|
you need to define <makevar>LUA_PREMK</makevar>.</para>
|
|
|
|
<important>
|
|
<para>If you define <makevar>LUA_PREMK</makevar>, then the
|
|
version, dependencies, components and defined variables
|
|
will not change if you modify the
|
|
<application>Lua</application> port variables
|
|
<emphasis>after</emphasis> including
|
|
<filename>bsd.port.pre.mk</filename>.</para>
|
|
</important>
|
|
|
|
<example id="lua-premk-example">
|
|
<title>Using <application>Lua</application> Variables in
|
|
Commands</title>
|
|
|
|
<para>The following fragment illustrates the use of
|
|
<makevar>LUA_PREMK</makevar> by running the
|
|
<application>Lua</application> interpreter to obtain the
|
|
full version string, assign it to a variable and pass it
|
|
to the program.</para>
|
|
|
|
<programlisting>USE_LUA= 5.0
|
|
LUA_PREMK= yes
|
|
|
|
.include <bsd.port.pre.mk>
|
|
|
|
.if exists(${LUA_CMD})
|
|
VER_STR!= ${LUA_CMD} -v
|
|
|
|
CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}"
|
|
.endif</programlisting>
|
|
</example>
|
|
|
|
<note>
|
|
<para>The <application>Lua</application> variables can be
|
|
safely used in commands when they are inside targets
|
|
without the need of <makevar>LUA_PREMK</makevar>.</para>
|
|
</note>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="using-xfce">
|
|
<title>Using Xfce</title>
|
|
|
|
<para>The <makevar>USE_XFCE</makevar> variable is used to
|
|
autoconfigure the dependencies for ports which use an Xfce
|
|
based library or application like <filename
|
|
role="package">x11-toolkits/libxfce4gui</filename> and
|
|
<filename role="package">x11-wm/xfce4-panel</filename>.</para>
|
|
|
|
<para>The following Xfce libraries and applications are
|
|
recognized at the moment:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>libexo: <filename
|
|
role="package">x11/libexo</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>libgui: <filename
|
|
role="package">x11-toolkits/libxfce4gui</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>libutil: <filename
|
|
role="package">x11/libxfce4util</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>libmcs: <filename
|
|
role="package">x11/libxfce4mcs</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>mcsmanager: <filename
|
|
role="package">sysutils/xfce4-mcs-manager</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>panel: <filename
|
|
role="package">x11-wm/xfce4-panel</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>thunar: <filename
|
|
role="package">x11-fm/thunar</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>wm: <filename
|
|
role="package">x11-wm/xfce4-wm</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>xfdev: <filename
|
|
role="package">dev/xfce4-dev-tools</filename></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The following additional parameters are recognized:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>configenv: Use this if your port requires a special
|
|
modified <makevar>CONFIGURE_ENV</makevar> to find its
|
|
required libraries.</para>
|
|
|
|
<programlisting>-I${LOCALBASE}/include -L${LOCALBASE}/lib</programlisting>
|
|
|
|
<para>gets added to CPPFLAGS to
|
|
<makevar>CONFIGURE_ENV</makevar>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Therefore, if a port has a dependency on <filename
|
|
role="package">sysutils/xfce4-mcs-manager</filename> and
|
|
requires the special CPPFLAGS in its configure environment,
|
|
the syntax will be:</para>
|
|
|
|
<programlisting>USE_XFCE= mcsmanager configenv</programlisting>
|
|
</sect1>
|
|
|
|
<sect1 id="using-mozilla">
|
|
<title>Using Mozilla</title>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports That Use Mozilla</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
|
|
<row>
|
|
<entry><makevar>USE_GECKO</makevar></entry>
|
|
<entry>Gecko backend the port can handle. Possible
|
|
values: <literal>libxul</literal>
|
|
(<filename>libxul.so</filename>),
|
|
<literal>seamonkey</literal>
|
|
(<filename>libgtkembedmoz.so</filename>, deprecated,
|
|
shouldn't be used any more).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_FIREFOX</makevar></entry>
|
|
<entry>The port requires Firefox as a runtime
|
|
dependency. Possible values: <literal>yes</literal>
|
|
(get default version), <literal>40</literal>,
|
|
<literal>36</literal>, <literal>35</literal>. Default
|
|
dependency is on version
|
|
<literal>40</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_FIREFOX_BUILD</makevar></entry>
|
|
<entry>The port requires Firefox as a buildtime
|
|
dependency. Possible values: see USE_FIREFOX. This
|
|
automatically sets USE_FIREFOX and assigns the same
|
|
value.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_SEAMONKEY</makevar></entry>
|
|
<entry>The port requires SeaMonkey as a runtime
|
|
dependency. Possible values: <literal>yes</literal>
|
|
(get default version), <literal>20</literal>,
|
|
<literal>11</literal> (deprecated, should not be used
|
|
any more). Default dependency is on version
|
|
<literal>20</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_SEAMONKEY_BUILD</makevar></entry>
|
|
<entry>The port requires SeaMonkey as a buildtime
|
|
dependency. Possible values: see USE_SEAMONKEY. This
|
|
automatically sets USE_SEAMONKEY and assigns the same
|
|
value.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_THUNDERBIRD</makevar></entry>
|
|
<entry>The port requires Thunderbird as a runtime
|
|
dependency. Possible values: <literal>yes</literal>
|
|
(get default version), <literal>31</literal>,
|
|
<literal>30</literal> (deprecated, should not be used
|
|
any more). Default dependency is on version
|
|
<literal>31</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_THUNDERBIRD_BUILD</makevar></entry>
|
|
<entry>The port requires Thunderbird as a buildtime
|
|
dependency. Possible values: see USE_THUNDERBIRD.
|
|
This automatically sets USE_THUNDERBIRD and assigns
|
|
the same value.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>A complete list of available variables can be found in
|
|
<filename>/usr/ports/Mk/bsd.gecko.mk</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="using-databases">
|
|
<title>Using Databases</title>
|
|
|
|
<table frame="none">
|
|
<title>Variables for Ports Using Databases</title>
|
|
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Means</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>USE_BDB</makevar></entry>
|
|
<entry>If variable is set to <literal>yes</literal>,
|
|
add dependency on <filename
|
|
role="package">databases/db41</filename> 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, <makevar>USE_BDB</makevar>=42+ will
|
|
find the highest installed version, and fall back to
|
|
42 if nothing else is installed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_MYSQL</makevar></entry>
|
|
<entry>If variable is set to <literal>yes</literal>, add
|
|
dependency on <filename
|
|
role="package">databases/mysql55-client</filename>
|
|
port. An associated variable,
|
|
<makevar>WANT_MYSQL_VER</makevar>, may be set to
|
|
values such as 323, 40, 41, 50, 51, 52, 55, or
|
|
60.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_PGSQL</makevar></entry>
|
|
<entry>If set to <literal>yes</literal>, add dependency
|
|
on <filename
|
|
role="package">databases/postgresql90-client</filename>
|
|
port. An associated variable,
|
|
<makevar>WANT_PGSQL_VER</makevar>, may be set to
|
|
values such as 83, 84, 90, 91 or 92. You can declare a
|
|
minimum or maximum value;
|
|
<makevar>WANT_PGSQL_VER</makevar>=
|
|
<literal> 90+</literal> will cause the
|
|
port to depend on a minimum version of 9.0.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>USE_SQLITE</makevar></entry>
|
|
<entry>If variable is set to <literal>yes</literal>, add
|
|
dependency on
|
|
<filename role="package">databases/sqlite3</filename>
|
|
port. The variable may also be set to values: 3,
|
|
2.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>More details are available in <ulink
|
|
url="http://svn.FreeBSD.org/ports/head/Mk/bsd.database.mk?view=markup">bsd.database.mk</ulink>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="rc-scripts">
|
|
<title>Starting and Stopping Services (<literal>rc</literal>
|
|
Scripts)</title>
|
|
|
|
<para><filename>rc.d</filename> 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 <filename>rc.d</filename>
|
|
framework. Details on its usage can be found in <ulink
|
|
url="&url.books.handbook;/configtuning-rcd.html">the rc.d
|
|
Handbook chapter</ulink>. Detailed explanation of available
|
|
commands is provided in &man.rc.8; and &man.rc.subr.8;.
|
|
Finally, there is <ulink url="&url.articles.rc-scripting">an
|
|
article</ulink> on practical aspects of
|
|
<filename>rc.d</filename> scripting.</para>
|
|
|
|
<para>One or more <filename>rc.d</filename> scripts can be
|
|
installed:</para>
|
|
|
|
<programlisting>USE_RC_SUBR= doormand</programlisting>
|
|
|
|
<para>Scripts must be placed in the <filename>files</filename>
|
|
subdirectory and a <literal>.in</literal> suffix must be added
|
|
to their filename. Standard <makevar>SUB_LIST</makevar>
|
|
expansions will be used for this file. Use of the
|
|
<literal>%%PREFIX%%</literal> and
|
|
<literal>%%LOCALBASE%%</literal> expansions is strongly
|
|
encouraged as well. More on <makevar>SUB_LIST</makevar> in
|
|
<link
|
|
linkend="using-sub-files">the relevant
|
|
section</link>.</para>
|
|
|
|
<para>Prior to &os; 6.1-RELEASE, integration with
|
|
&man.rcorder.8; is available by using
|
|
<makevar>USE_RCORDER</makevar> instead of
|
|
<makevar>USE_RC_SUBR</makevar>. However, use of this method
|
|
is not necessary unless the port has an option to install
|
|
itself in the base, or the service needs to run prior to the
|
|
<filename>FILESYSTEMS</filename> <filename>rc.d</filename>
|
|
script in the base.</para>
|
|
|
|
<para>As of &os; 6.1-RELEASE, local
|
|
<filename>rc.d</filename> scripts (including those installed
|
|
by ports) are included in the overall &man.rcorder.8; of the
|
|
base system.</para>
|
|
|
|
<para>Example simple <filename>rc.d</filename> script:</para>
|
|
|
|
<programlisting>#!/bin/sh
|
|
|
|
# $FreeBSD$
|
|
#
|
|
# PROVIDE: doormand
|
|
# REQUIRE: LOGIN
|
|
# KEYWORD: shutdown
|
|
#
|
|
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
|
|
# to enable this service:
|
|
#
|
|
# doormand_enable (bool): Set to NO by default.
|
|
# Set it to YES to enable doormand.
|
|
# doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf
|
|
# by default.
|
|
|
|
. /etc/rc.subr
|
|
|
|
name=doormand
|
|
rcvar=doormand_enable
|
|
|
|
load_rc_config $name
|
|
|
|
: ${doormand_enable:="NO"}
|
|
: ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"}
|
|
|
|
command=%%PREFIX%%/sbin/${name}
|
|
pidfile=/var/run/${name}.pid
|
|
|
|
command_args="-p $pidfile -f $doormand_config"
|
|
|
|
run_rc_command "$1"</programlisting>
|
|
|
|
<para> Unless there is a good reason to start the service
|
|
earlier all ports scripts should use</para>
|
|
|
|
<programlisting>REQUIRE: LOGIN</programlisting>
|
|
|
|
<para>If the service runs as a particular user (other than root)
|
|
this is mandatory.</para>
|
|
|
|
<programlisting>KEYWORD: shutdown</programlisting>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>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 <emphasis>or</emphasis> null. A user
|
|
might very well include something like</para>
|
|
|
|
<programlisting>doormand_flags=""</programlisting>
|
|
|
|
<para>in their <filename>rc.conf.local</filename> file, and a
|
|
variable substitution using ":=" would
|
|
inappropriately override the user's intention. The
|
|
<literal>_enable</literal> variable is not optional,
|
|
and should use the ":" for the default.</para>
|
|
|
|
<note>
|
|
<para>No new scripts should be added with the
|
|
<filename>.sh</filename> suffix.</para>
|
|
</note>
|
|
|
|
<sect2>
|
|
<title>Stopping Services at Deinstall</title>
|
|
|
|
<para>It is possible to have a service stopped automatically
|
|
as part of the deinstall routine. We advise using this
|
|
feature only when it is absolutely necessary to stop a
|
|
service before its files go away. Usually, it is up to the
|
|
administrator's discretion to decide, whether to stop the
|
|
service on deinstall or not. Also note this affects
|
|
upgrades, too.</para>
|
|
|
|
<para>A line like this goes in the
|
|
<filename>pkg-plist</filename>:</para>
|
|
|
|
<programlisting>@stopdaemon doormand</programlisting>
|
|
|
|
<para>The argument must match the content of
|
|
<makevar>USE_RC_SUBR</makevar> variable.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Pre-Commit Checklist</title>
|
|
|
|
<para>Before contributing a port with an
|
|
<filename>rc.d</filename> script, and more importantly,
|
|
before committing one, please consult the following
|
|
checklist to be sure that it is ready.</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>If this is a new file, does it have
|
|
<filename>.sh</filename> in the file name? If so that
|
|
should be changed to just <filename>file.in</filename>
|
|
since new <filename>rc.d</filename> files may not end
|
|
with that extension.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Does the file have a
|
|
<literal>$FreeBSD$</literal> tag?</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Do the name of the file (minus
|
|
<filename>.in</filename>), the
|
|
<literal>PROVIDE</literal> line, and
|
|
<literal>$</literal><replaceable>name</replaceable>
|
|
all match? The file name matching
|
|
<literal>PROVIDE</literal> makes debugging easier,
|
|
especially for &man.rcorder.8; issues. Matching the
|
|
file name and
|
|
<literal>$</literal><replaceable>name</replaceable>
|
|
makes it easier to figure out which variables are
|
|
relevant in <filename>rc.conf[.local]</filename>. The
|
|
latter is also what you might call “policy”
|
|
for all new scripts, including those in the base
|
|
system.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Is the <literal>REQUIRE</literal> line set to
|
|
<literal>LOGIN</literal>? 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
|
|
<literal>LOGIN</literal>? 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.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Does the script start a persistent service? If so,
|
|
it should have <literal>KEYWORD:
|
|
shutdown</literal>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
|
|
<para>Make sure there is no <literal>KEYWORD:
|
|
FreeBSD</literal> 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.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>If the script uses an interpreted language like
|
|
<command>perl</command>, <command>python</command>, or
|
|
<command>ruby</command>, make certain that
|
|
<varname>command_interpreter</varname> is set
|
|
appropriately. Otherwise,</para>
|
|
|
|
<screen>&prompt.root; <userinput>service <replaceable>name</replaceable> stop</userinput></screen>
|
|
|
|
<para>will probably not work properly. See
|
|
&man.service.8; for more information.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Have all occurrences of
|
|
<filename>/usr/local</filename> been replaced with
|
|
<literal>%%PREFIX%%</literal>?</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Do the default variable assignments come after
|
|
<function>load_rc_config</function>?</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>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.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Are things that are set in variables actually used
|
|
in the script?</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Are options listed in the default
|
|
<replaceable>name</replaceable><varname>_flags</varname>
|
|
things that are actually mandatory? If so, they should
|
|
be in <varname>command_args</varname>. The
|
|
<option>-d</option> option is a red flag (pardon the
|
|
pun) here, since it is usually the option to
|
|
“daemonize” the process, and therefore is
|
|
actually mandatory.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>The
|
|
<replaceable>name</replaceable><varname>_flags</varname>
|
|
variable should never be included in
|
|
<varname>command_args</varname> (and vice versa,
|
|
although that error is less common).</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Does the script execute any code unconditionally?
|
|
This is frowned on. Usually these things can/should be
|
|
dealt with through a
|
|
<function>start_precmd</function>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>All boolean tests should utilize the
|
|
<function>checkyesno</function> function. No
|
|
hand-rolled tests for <literal>[Yy][Ee][Ss]</literal>,
|
|
etc.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>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.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Does the script create files or directories that
|
|
need specific permissions, for example, a
|
|
<filename>pid</filename> 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.</para>
|
|
</step>
|
|
</procedure>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="users-and-groups">
|
|
<title>Adding Users and Groups</title>
|
|
|
|
<para>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 <filename>ports/UIDs</filename> (for users) or in
|
|
<filename>ports/GIDs</filename> (for groups). Make sure you
|
|
do not use a UID already used by the system or other
|
|
ports.</para>
|
|
|
|
<para>Please include a patch against these two files when you
|
|
require a new user or group to be created for your
|
|
port.</para>
|
|
|
|
<para>Then you can use <makevar>USERS</makevar> and
|
|
<makevar>GROUPS</makevar> variables in your
|
|
<filename>Makefile</filename>, and the user will be
|
|
automatically created when installing the port.</para>
|
|
|
|
<programlisting>USERS= pulse
|
|
GROUPS= pulse pulse-access pulse-rt</programlisting>
|
|
|
|
<para>The current list of reserved UIDs and GIDs can be found
|
|
in <filename>ports/UIDs</filename> and
|
|
<filename>ports/GIDs</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="requiring-kernel-sources">
|
|
<title>Ports That Rely on Kernel Sources</title>
|
|
|
|
<para>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:</para>
|
|
|
|
<programlisting>.if !exists(${SRC_BASE}/sys/Makefile)
|
|
IGNORE= requires kernel sources to be installed
|
|
.endif</programlisting>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="plist">
|
|
<title>Advanced <filename>pkg-plist</filename> Practices</title>
|
|
|
|
<sect1 id="plist-sub">
|
|
<title>Changing <filename>pkg-plist</filename> Based on Make
|
|
Variables</title>
|
|
|
|
<para>Some ports, particularly the <literal>p5-</literal> ports,
|
|
need to change their <filename>pkg-plist</filename> depending
|
|
on what options they are configured with (or version of
|
|
<literal>perl</literal>, in the case of <literal>p5-</literal>
|
|
ports). To make this easy, any instances in the
|
|
<filename>pkg-plist</filename> of
|
|
<literal>%%OSREL%%</literal>, <literal>%%PERL_VER%%</literal>,
|
|
and <literal>%%PERL_VERSION%%</literal> will be substituted
|
|
for appropriately. The value of <literal>%%OSREL%%</literal>
|
|
is the numeric revision of the operating system (e.g.,
|
|
<literal>4.9</literal>). <literal>%%PERL_VERSION%%</literal>
|
|
and <literal>%%PERL_VER%%</literal> is the full version number
|
|
of <command>perl</command> (e.g., <literal>5.8.9</literal>).
|
|
Several other
|
|
<literal>%%<replaceable>VARS</replaceable>%%</literal> related
|
|
to port's documentation files are described in <link
|
|
linkend="install-documentation">the relevant
|
|
section</link>.</para>
|
|
|
|
<para>If you need to make other substitutions, you can set the
|
|
<makevar>PLIST_SUB</makevar> variable with a list of
|
|
<literal><replaceable>VAR</replaceable>=<replaceable>VALUE</replaceable></literal>
|
|
pairs and instances of
|
|
<literal>%%<replaceable>VAR</replaceable>%%</literal> will be
|
|
substituted with <replaceable>VALUE</replaceable> in the
|
|
<filename>pkg-plist</filename>.</para>
|
|
|
|
<para>For instance, if you have a port that installs many files
|
|
in a version-specific subdirectory, you can put something
|
|
like</para>
|
|
|
|
<programlisting>OCTAVE_VERSION= 2.0.13
|
|
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}</programlisting>
|
|
|
|
<para>in the <filename>Makefile</filename> and use
|
|
<literal>%%OCTAVE_VERSION%%</literal> wherever the version
|
|
shows up in <filename>pkg-plist</filename>. That way, when
|
|
you upgrade the port, you will not have to change dozens (or
|
|
in some cases, hundreds) of lines in the
|
|
<filename>pkg-plist</filename>.</para>
|
|
|
|
<para>If your port installs files conditionally on the options
|
|
set in the port, the usual way of handling it is prefixing the
|
|
<filename>pkg-plist</filename> lines with a
|
|
<literal>%%TAG%%</literal> and adding that
|
|
<literal>TAG</literal> to the <makevar>PLIST_SUB</makevar>
|
|
variable inside the <filename>Makefile</filename> with a
|
|
special value of <literal>@comment</literal>, which makes
|
|
package tools to ignore the line:</para>
|
|
|
|
<programlisting>.if defined(WITH_X11)
|
|
PLIST_SUB+= X11=""
|
|
.else
|
|
PLIST_SUB+= X11="@comment "
|
|
.endif</programlisting>
|
|
|
|
<para>and in the <filename>pkg-plist</filename>:</para>
|
|
|
|
<programlisting>%%X11%%bin/foo-gui</programlisting>
|
|
|
|
<para>This substitution (as well as addition of any <link
|
|
linkend="makefile-manpages">manual pages</link>) will be
|
|
done between the <maketarget>pre-install</maketarget> and
|
|
<maketarget>do-install</maketarget> targets, by reading from
|
|
<filename><makevar>PLIST</makevar></filename> and writing to
|
|
<filename><makevar>TMPPLIST</makevar></filename> (default:
|
|
<filename><makevar>WRKDIR</makevar>/.PLIST.mktmp</filename>).
|
|
So if your port builds
|
|
<filename><makevar>PLIST</makevar></filename> on the fly, do
|
|
so in or before <maketarget>pre-install</maketarget>. Also,
|
|
if your port needs to edit the resulting file, do so in
|
|
<maketarget>post-install</maketarget> to a file named
|
|
<filename><makevar>TMPPLIST</makevar></filename>.</para>
|
|
|
|
<para>Another possibility to modify port's packing list is based
|
|
on setting the variables <makevar>PLIST_FILES</makevar> and
|
|
<makevar>PLIST_DIRS</makevar>. The value of each variable is
|
|
regarded as a list of pathnames to write to
|
|
<filename><makevar>TMPPLIST</makevar></filename> along with
|
|
<filename><makevar>PLIST</makevar></filename> contents. Names
|
|
listed in <makevar>PLIST_FILES</makevar> and
|
|
<makevar>PLIST_DIRS</makevar> are subject to
|
|
<literal>%%<replaceable>VAR</replaceable>%%</literal>
|
|
substitution, as described above. Except for that, names from
|
|
<makevar>PLIST_FILES</makevar> will appear in the final
|
|
packing list unchanged, while <literal>@dirrm</literal> will
|
|
be prepended to names from <makevar>PLIST_DIRS</makevar>. To
|
|
take effect, <makevar>PLIST_FILES</makevar> and
|
|
<makevar>PLIST_DIRS</makevar> must be set before
|
|
<filename><makevar>TMPPLIST</makevar></filename> is written,
|
|
i.e., in <maketarget>pre-install</maketarget> or
|
|
earlier.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="plist-cleaning">
|
|
<title>Empty Directories</title>
|
|
|
|
<sect2 id="plist-dir-cleaning">
|
|
<title>Cleaning Up Empty Directories</title>
|
|
|
|
<para>Do make your ports remove empty directories when they
|
|
are de-installed. This is usually accomplished by adding
|
|
<literal>@dirrm</literal> lines for all directories that are
|
|
specifically created by the port. You need to delete
|
|
subdirectories before you can delete parent
|
|
directories.</para>
|
|
|
|
<programlisting> :
|
|
lib/X11/oneko/pixmaps/cat.xpm
|
|
lib/X11/oneko/sounds/cat.au
|
|
:
|
|
@dirrm lib/X11/oneko/pixmaps
|
|
@dirrm lib/X11/oneko/sounds
|
|
@dirrm lib/X11/oneko</programlisting>
|
|
|
|
<para>However, sometimes <literal>@dirrm</literal> will give
|
|
you errors because other ports share the same directory.
|
|
You can use <literal>@dirrmtry</literal> to remove only
|
|
empty directories without warning.</para>
|
|
|
|
<programlisting>@dirrmtry share/doc/gimp</programlisting>
|
|
|
|
<para>This will neither print any error messages nor cause
|
|
&man.pkg.delete.1; to exit abnormally even if
|
|
<filename><makevar>${PREFIX}</makevar>/share/doc/gimp</filename>
|
|
is not empty due to other ports installing some files in
|
|
there.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="plist-dir-empty">
|
|
<title>Creating Empty Directories</title>
|
|
|
|
<para>Empty directories created during port installation need
|
|
special attention. They will not get created when
|
|
installing the package, because packages only store the
|
|
files, and &man.pkg.add.1; creates directories for them as
|
|
needed. To make sure the empty directory is created when
|
|
installing the package, add this line to
|
|
<filename>pkg-plist</filename> above the corresponding
|
|
<literal>@dirrm</literal> line:</para>
|
|
|
|
<programlisting>@exec mkdir -p %D/share/foo/templates</programlisting>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="plist-config">
|
|
<title>Configuration Files</title>
|
|
|
|
<para>If your port installs configuration files to
|
|
<filename><makevar>PREFIX</makevar>/etc</filename> (or
|
|
elsewhere) do <emphasis>not</emphasis> simply list them in the
|
|
<filename>pkg-plist</filename>. That will cause
|
|
&man.pkg.delete.1; to remove the files carefully edited by
|
|
the user, and a re-installation will wipe them out.</para>
|
|
|
|
<para>Instead, install sample file(s) with a
|
|
<filename><replaceable>filename</replaceable>.sample</filename>
|
|
suffix. Then copy the sample file to the real configuration
|
|
file name, if it does not already exist. On deinstall
|
|
delete the configuration file, but only if it is identical
|
|
to the <filename>.sample</filename> file.
|
|
You need to handle this both in the port
|
|
<filename>Makefile</filename>, and in the
|
|
<filename>pkg-plist</filename> (for installation from the
|
|
package).</para>
|
|
|
|
<para>Example of the <filename>Makefile</filename> part:</para>
|
|
|
|
<programlisting>post-install:
|
|
@if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \
|
|
${CP} -p ${PREFIX}/etc/orbit.conf.sample ${PREFIX}/etc/orbit.conf ; \
|
|
fi</programlisting>
|
|
|
|
<para>For each configuration file, create the following three
|
|
lines in <filename>pkg-plist</filename>:</para>
|
|
|
|
<programlisting>@unexec if cmp -s %D/etc/orbit.conf.sample %D/etc/orbit.conf; then rm -f %D/etc/orbit.conf; fi
|
|
etc/orbit.conf.sample
|
|
@exec if [ ! -f %D/etc/orbit.conf ] ; then cp -p %D/%F %B/orbit.conf; fi</programlisting>
|
|
|
|
<para>The order of these lines is important. On deinstallation,
|
|
the sample file is compared to the actual configuration file.
|
|
If these files are identical, no changes have been made by the
|
|
user and the actual file can be safely deleted. Because the
|
|
sample file must still exist for the comparison, the
|
|
<literal>@unexec</literal> line comes before the sample
|
|
configuration file name. On installation, if an actual
|
|
configuration file is not already present, the sample file is
|
|
copied to the actual file. The sample file must be present
|
|
before it can be copied, so the <literal>@exec</literal> line
|
|
comes after the sample configuration file name.</para>
|
|
|
|
<para>To debug any issues, temporarily remove the
|
|
<literal>-s</literal> flag to &man.cmp.1; for more
|
|
output.</para>
|
|
|
|
<para>See &man.pkg.create.1; for more information on
|
|
<literal>%D</literal> and related substitution markers.</para>
|
|
|
|
<para>If there is a very good reason not to install a working
|
|
configuration file by default, leave the
|
|
<literal>@exec</literal> line out of
|
|
<filename>pkg-plist</filename> and add a <link
|
|
linkend="porting-message">message</link> pointing out that
|
|
the user must copy and edit the file before the software will
|
|
work.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="plist-dynamic">
|
|
<title>Dynamic Versus Static Package List</title>
|
|
|
|
<para>A <emphasis>static package list</emphasis> is a package
|
|
list which is available in the Ports Collection either as a
|
|
<filename>pkg-plist</filename> file (with or without variable
|
|
substitution), or embedded into the
|
|
<filename>Makefile</filename> via
|
|
<makevar>PLIST_FILES</makevar> and
|
|
<makevar>PLIST_DIRS</makevar>. Even if the contents are
|
|
auto-generated by a tool or a target in the Makefile
|
|
<emphasis>before</emphasis> the inclusion into the Ports
|
|
Collection by a committer, this is still considered a static
|
|
list, since it is possible to examine it without having to
|
|
download or compile the distfile.</para>
|
|
|
|
<para>A <emphasis>dynamic package list</emphasis> is a package
|
|
list which is generated at the time the port is compiled based
|
|
upon the files and directories which are installed. It is not
|
|
possible to examine it before the source code of the ported
|
|
application is downloaded and compiled, or after running a
|
|
<literal>make clean</literal>.</para>
|
|
|
|
<para>While the use of dynamic package lists is not forbidden,
|
|
maintainers should use static package lists wherever possible,
|
|
as it enables users to &man.grep.1; through available ports to
|
|
discover, for example, which port installs a certain file.
|
|
Dynamic lists should be primarily used for complex ports where
|
|
the package list changes drastically based upon optional
|
|
features of the port (and thus maintaining a static package
|
|
list is infeasible), or ports which change the package list
|
|
based upon the version of dependent software used (e.g., ports
|
|
which generate docs with
|
|
<application>Javadoc</application>).</para>
|
|
|
|
<para>Maintainers who prefer dynamic package lists are
|
|
encouraged to add a new target to their port which generates
|
|
the <filename>pkg-plist</filename> file so that users may
|
|
examine the contents.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="plist-autoplist">
|
|
<title>Automated Package List Creation</title>
|
|
|
|
<para>First, make sure your port is almost complete, with only
|
|
<filename>pkg-plist</filename> missing.</para>
|
|
|
|
<para>Next, create a temporary directory tree into which your
|
|
port can be installed, and install any dependencies.</para>
|
|
|
|
<screen>&prompt.root; <userinput>mkdir /var/tmp/`make -V PORTNAME`</userinput>
|
|
&prompt.root; <userinput>mtree -U -f `make -V MTREE_FILE` -d -e -p /var/tmp/`make -V PORTNAME`</userinput>
|
|
&prompt.root; <userinput>make depends PREFIX=/var/tmp/`make -V PORTNAME`</userinput></screen>
|
|
|
|
<para>Store the directory structure in a new file.</para>
|
|
|
|
<screen>&prompt.root; <userinput>(cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort > OLD-DIRS</userinput></screen>
|
|
|
|
<para>Create an empty <filename>pkg-plist</filename>
|
|
file:</para>
|
|
|
|
<screen>&prompt.root; <userinput>:>pkg-plist</userinput></screen>
|
|
|
|
<para>If your port honors <makevar>PREFIX</makevar> (which it
|
|
should) you can then install the port and create the package
|
|
list.</para>
|
|
|
|
<screen>&prompt.root; <userinput>make install PREFIX=/var/tmp/`make -V PORTNAME`</userinput>
|
|
&prompt.root; <userinput>(cd /var/tmp/`make -V PORTNAME` && find -d * \! -type d) | sort > pkg-plist</userinput></screen>
|
|
|
|
<para>You must also add any newly created directories to the
|
|
packing list.</para>
|
|
|
|
<screen>&prompt.root; <userinput>(cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort | comm -13 OLD-DIRS - | sort -r | sed -e 's#^#@dirrm #' >> pkg-plist</userinput></screen>
|
|
|
|
<para>Finally, you need to tidy up the packing list by hand; it
|
|
is not <emphasis>all</emphasis> automated. Manual pages
|
|
should be listed in the port's <filename>Makefile</filename>
|
|
under <makevar>MAN<replaceable>n</replaceable></makevar>, and
|
|
not in the package list. User configuration files should be
|
|
removed, or installed as
|
|
<filename><replaceable>filename</replaceable>.sample</filename>.
|
|
The <filename>info/dir</filename> file should not be listed
|
|
and appropriate <filename>install-info</filename> lines should
|
|
be added as noted in the <link linkend="makefile-info">info
|
|
files</link> section. Any libraries installed by the port
|
|
should be listed as specified in the <link
|
|
linkend="porting-shlibs">shared libraries</link>
|
|
section.</para>
|
|
|
|
<para>Alternatively, use the <command>plist</command> script in
|
|
<filename>/usr/ports/Tools/scripts/</filename> to build the
|
|
package list automatically. The <filename>plist</filename>
|
|
script is a <application>Ruby</application> script that
|
|
automates most of the manual steps outlined in the previous
|
|
paragraphs.</para>
|
|
|
|
<para>The first step is the same as above: take the first three
|
|
lines, that is, <command>mkdir</command>,
|
|
<command>mtree</command> and <command>make depends</command>.
|
|
Then build and install the port:</para>
|
|
|
|
<screen>&prompt.root; <userinput>make install PREFIX=/var/tmp/`make -V PORTNAME`</userinput></screen>
|
|
|
|
<para>And let <command>plist</command> create the
|
|
<filename>pkg-plist</filename> file:</para>
|
|
|
|
<screen>&prompt.root; <userinput>/usr/ports/Tools/scripts/plist -Md -m `make -V MTREE_FILE` /var/tmp/`make -V PORTNAME` > pkg-plist</userinput></screen>
|
|
|
|
<para>The packing list still has to be tidied up by hand as
|
|
stated above.</para>
|
|
|
|
<para>Another tool that might be used to create an initial
|
|
<filename>pkg-plist</filename> is <filename
|
|
role="package">ports-mgmt/genplist</filename>. As with any
|
|
automated tool, the resulting <filename>pkg-plist</filename>
|
|
should be checked and manually edited as needed.</para>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="pkg-files">
|
|
<title>The <filename>pkg-<replaceable>*</replaceable></filename>
|
|
Files</title>
|
|
|
|
<para>There are some tricks we have not mentioned yet about the
|
|
<filename>pkg-<replaceable>*</replaceable></filename> files
|
|
that come in handy sometimes.</para>
|
|
|
|
<sect1 id="porting-message">
|
|
<title><filename>pkg-message</filename></title>
|
|
|
|
<para>If you need to display a message to the installer, you may
|
|
place the message in <filename>pkg-message</filename>. This
|
|
capability is often useful to display additional installation
|
|
steps to be taken after a &man.pkg.add.1; or to display
|
|
licensing information.</para>
|
|
|
|
<para>When some lines about the build-time knobs or warnings
|
|
have to be displayed, use <makevar>ECHO_MSG</makevar>. The
|
|
<filename>pkg-message</filename> file is only for
|
|
post-installation steps. Likewise, the distinction between
|
|
<makevar>ECHO_MSG</makevar> and <makevar>ECHO_CMD</makevar>
|
|
should be kept in mind. The former is for printing
|
|
informational text to the screen, while the latter is for
|
|
command pipelining:</para>
|
|
|
|
<programlisting>update-etc-shells:
|
|
@${ECHO_MSG} "updating /etc/shells"
|
|
@${CP} /etc/shells /etc/shells.bak
|
|
@( ${GREP} -v ${PREFIX}/bin/bash /etc/shells.bak; \
|
|
${ECHO_CMD} ${PREFIX}/bin/bash) >/etc/shells
|
|
@${RM} /etc/shells.bak</programlisting>
|
|
|
|
<note>
|
|
<para>The <filename>pkg-message</filename> file does not need
|
|
to be added to <filename>pkg-plist</filename>. Also, it
|
|
will not get automatically printed if the user is using the
|
|
port, not the package, so you should probably display it
|
|
from the <maketarget>post-install</maketarget> target
|
|
yourself.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="pkg-install">
|
|
<title><filename>pkg-install</filename></title>
|
|
|
|
<para>If your port needs to execute commands when the binary
|
|
package is installed with &man.pkg.add.1; you can do this via
|
|
the <filename>pkg-install</filename> script. This script will
|
|
automatically be added to the package, and will be run twice
|
|
by &man.pkg.add.1;: the first time as <literal>${SH}
|
|
pkg-install ${PKGNAME} PRE-INSTALL</literal> and the
|
|
second time as <literal>${SH} pkg-install
|
|
${PKGNAME} POST-INSTALL</literal>.
|
|
<literal>$2</literal> can be tested to determine which
|
|
mode the script is being run in. The
|
|
<envar>PKG_PREFIX</envar> environmental variable will be set
|
|
to the package installation directory. See &man.pkg.add.1;
|
|
for additional information.</para>
|
|
|
|
<note>
|
|
<para>This script is not run automatically if you install the
|
|
port with <command>make install</command>. If you are
|
|
depending on it being run, you will have to explicitly call
|
|
it from your port's <filename>Makefile</filename>, with a
|
|
line like <literal>PKG_PREFIX=${PREFIX} ${SH}
|
|
${PKGINSTALL} ${PKGNAME}
|
|
PRE-INSTALL</literal>.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="pkg-deinstall">
|
|
<title><filename>pkg-deinstall</filename></title>
|
|
|
|
<para>This script executes when a package is removed.</para>
|
|
|
|
<para>This script will be run twice by &man.pkg.delete.1;.
|
|
The first time as <literal>${SH} pkg-deinstall
|
|
${PKGNAME} DEINSTALL</literal> and the second time as
|
|
<literal>${SH} pkg-deinstall ${PKGNAME}
|
|
POST-DEINSTALL</literal>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="pkg-req">
|
|
<title><filename>pkg-req</filename></title>
|
|
|
|
<para>If your port needs to determine if it should install or
|
|
not, you can create a <filename>pkg-req</filename>
|
|
<quote>requirements</quote> script. It will be invoked
|
|
automatically at installation/de-installation time to
|
|
determine whether or not installation/de-installation should
|
|
proceed.</para>
|
|
|
|
<para>The script will be run at installation time by
|
|
&man.pkg.add.1; as
|
|
<literal>pkg-req ${PKGNAME} INSTALL</literal>.
|
|
At de-installation time it will be run by
|
|
&man.pkg.delete.1; as
|
|
<literal>pkg-req ${PKGNAME} DEINSTALL</literal>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="pkg-names">
|
|
<title id="porting-pkgfiles">Changing the Names of
|
|
<filename>pkg-<replaceable>*</replaceable></filename>
|
|
Files</title>
|
|
|
|
<para>All the names of
|
|
<filename>pkg-<replaceable>*</replaceable></filename> files
|
|
are defined using variables so you can change them in your
|
|
<filename>Makefile</filename> if need be. This is especially
|
|
useful when you are sharing the same
|
|
<filename>pkg-<replaceable>*</replaceable></filename> files
|
|
among several ports or have to write to one of the above files
|
|
(see <link linkend="porting-wrkdir">writing to places other
|
|
than <makevar>WRKDIR</makevar></link> for why it is a bad
|
|
idea to write directly into the
|
|
<filename>pkg-<replaceable>*</replaceable></filename>
|
|
subdirectory).</para>
|
|
|
|
<para>Here is a list of variable names and their default values.
|
|
(<makevar>PKGDIR</makevar> defaults to
|
|
<makevar>${MASTERDIR}</makevar>.)</para>
|
|
|
|
<informaltable frame="none" pgwide="0">
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Default value</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>DESCR</makevar></entry>
|
|
<entry><literal>${PKGDIR}/pkg-descr</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PLIST</makevar></entry>
|
|
<entry><literal>${PKGDIR}/pkg-plist</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PKGINSTALL</makevar></entry>
|
|
<entry><literal>${PKGDIR}/pkg-install</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PKGDEINSTALL</makevar></entry>
|
|
<entry><literal>${PKGDIR}/pkg-deinstall</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PKGREQ</makevar></entry>
|
|
<entry><literal>${PKGDIR}/pkg-req</literal></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PKGMESSAGE</makevar></entry>
|
|
<entry><literal>${PKGDIR}/pkg-message</literal></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>Please change these variables rather than overriding
|
|
<makevar>PKG_ARGS</makevar>. If you change
|
|
<makevar>PKG_ARGS</makevar>, those files will not correctly be
|
|
installed in <filename>/var/db/pkg</filename> upon install
|
|
from a port.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="using-sub-files">
|
|
<title>Making Use of <makevar>SUB_FILES</makevar> and
|
|
<makevar>SUB_LIST</makevar></title>
|
|
|
|
<para>The <makevar>SUB_FILES</makevar> and
|
|
<makevar>SUB_LIST</makevar> variables are useful for dynamic
|
|
values in port files, such as the installation
|
|
<makevar>PREFIX</makevar> in
|
|
<filename>pkg-message</filename>.</para>
|
|
|
|
<para>The <makevar>SUB_FILES</makevar> variable specifies a list
|
|
of files to be automatically modified. Each
|
|
<replaceable>file</replaceable> in the
|
|
<makevar>SUB_FILES</makevar> list must have a corresponding
|
|
<filename><replaceable>file</replaceable>.in</filename>
|
|
present in <makevar>FILESDIR</makevar>. A modified version
|
|
will be created in <makevar>WRKDIR</makevar>. Files defined
|
|
as a value of <makevar>USE_RC_SUBR</makevar> (or the
|
|
deprecated <makevar>USE_RCORDER</makevar>) are automatically
|
|
added to the <makevar>SUB_FILES</makevar>. For the files
|
|
<filename>pkg-message</filename>,
|
|
<filename>pkg-install</filename>,
|
|
<filename>pkg-deinstall</filename> and
|
|
<filename>pkg-req</filename>, the corresponding Makefile
|
|
variable is automatically set to point to the processed
|
|
version.</para>
|
|
|
|
<para>The <makevar>SUB_LIST</makevar> variable is a list of
|
|
<literal>VAR=VALUE</literal> pairs. For each pair
|
|
<literal>%%VAR%%</literal> will get replaced with
|
|
<literal>VALUE</literal> in each file listed in
|
|
<makevar>SUB_FILES</makevar>. Several common pairs are
|
|
automatically defined: <makevar>PREFIX</makevar>,
|
|
<makevar>LOCALBASE</makevar>, <makevar>DATADIR</makevar>,
|
|
<makevar>DOCSDIR</makevar>, <makevar>EXAMPLESDIR</makevar>.
|
|
Any line beginning with <literal>@comment</literal> will be
|
|
deleted from resulting files after a variable
|
|
substitution.</para>
|
|
|
|
<para>The following example will replace
|
|
<literal>%%ARCH%%</literal> with the system architecture in a
|
|
<filename>pkg-message</filename>:</para>
|
|
|
|
<programlisting>SUB_FILES= pkg-message
|
|
SUB_LIST= ARCH=${ARCH}</programlisting>
|
|
|
|
<para>Note that for this example, the
|
|
<filename>pkg-message.in</filename> file must exist in
|
|
<makevar>FILESDIR</makevar>.</para>
|
|
|
|
<para>Example of a good
|
|
<filename>pkg-message.in</filename>:</para>
|
|
|
|
<programlisting>Now it is time to configure this package.
|
|
Copy %%PREFIX%%/share/examples/putsy/%%ARCH%%.conf into your home directory
|
|
as .putsy.conf and edit it.</programlisting>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="testing">
|
|
<title>Testing Your Port</title>
|
|
|
|
<sect1 id="make-describe">
|
|
<title>Running <command>make describe</command></title>
|
|
|
|
<para>Several of the &os; port maintenance tools, such as
|
|
&man.portupgrade.1;, rely on a database called
|
|
<filename>/usr/ports/INDEX</filename> which keeps track of
|
|
such items as port dependencies. <filename>INDEX</filename>
|
|
is created by the top-level
|
|
<filename>ports/Makefile</filename> via <command>make
|
|
index</command>, which descends into each port subdirectory
|
|
and executes <command>make describe</command> there. Thus, if
|
|
<command>make describe</command> fails in any port, no one can
|
|
generate <filename>INDEX</filename>, and many people will
|
|
quickly become unhappy.</para>
|
|
|
|
<note>
|
|
<para>It is important to be able to generate this file no
|
|
matter what options are present in
|
|
<filename>make.conf</filename>, so please avoid doing things
|
|
such as using <literal>.error</literal> statements when (for
|
|
instance) a dependency is not satisfied. (See <xref
|
|
linkend="dads-dot-error"/>.)</para>
|
|
</note>
|
|
|
|
<para>If <command>make describe</command> produces a string
|
|
rather than an error message, you are probably safe. See
|
|
<filename>bsd.port.mk</filename> for the meaning of the
|
|
string produced.</para>
|
|
|
|
<para>Also note that running a recent version of
|
|
<command>portlint</command> (as specified in the next section)
|
|
will cause <command>make describe</command> to be run
|
|
automatically.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="testing-portlint">
|
|
<title>Portlint</title>
|
|
|
|
<para>Do check your work with <link
|
|
linkend="porting-portlint"><command>portlint</command></link>
|
|
before you submit or commit it. <command>portlint</command>
|
|
warns you about many common errors, both functional and
|
|
stylistic. For a new (or repocopied) port, <command>portlint
|
|
-A</command> is the most thorough; for an existing port,
|
|
<command>portlint -C</command> is sufficient.</para>
|
|
|
|
<para>Since <command>portlint</command> uses heuristics to
|
|
try to figure out errors, it can produce false positive
|
|
warnings. In addition, occasionally something that is
|
|
flagged as a problem really cannot be done in any other
|
|
way due to limitations in the ports framework. When in
|
|
doubt, the best thing to do is ask on &a.ports;.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="testing-porttools">
|
|
<title>Port Tools</title>
|
|
|
|
<para>The <filename
|
|
role="package">ports-mgmt/porttools</filename> program is
|
|
part of the Ports Collection.</para>
|
|
|
|
<para><command>port</command> is the front-end script, which can
|
|
help you simplify the testing job. Whenever you want to test
|
|
a new port or update an existing one, you can use
|
|
<command>port test</command> to test your port, including the
|
|
<link
|
|
linkend="testing-portlint"><command>portlint</command></link>
|
|
checking. This command also detects and lists any files that
|
|
are not listed in <filename>pkg-plist</filename>. See the
|
|
following example:</para>
|
|
|
|
<screen>&prompt.root; <userinput>port test /usr/ports/net/csup</userinput></screen>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-prefix">
|
|
<title><makevar>PREFIX</makevar> and
|
|
<makevar>DESTDIR</makevar></title>
|
|
|
|
<para><makevar>PREFIX</makevar> determines where the port will
|
|
be installed. It defaults to <filename>/usr/local</filename>,
|
|
but can be set by the user to a custom path like
|
|
<filename>/opt</filename>. Your port must respect the value
|
|
of this variable.</para>
|
|
|
|
<para><makevar>DESTDIR</makevar>, if set by the user, determines
|
|
the complete alternative environment, usually a jail or an
|
|
installed system mounted somewhere other than
|
|
<filename>/</filename>. A port will actually install into
|
|
<filename><makevar>DESTDIR</makevar>/<makevar>PREFIX</makevar></filename>,
|
|
and register with the package database in
|
|
<filename><makevar>DESTDIR</makevar>/var/db/pkg</filename>.
|
|
As <makevar>DESTDIR</makevar> is handled automatically by the
|
|
ports infrastructure with &man.chroot.8;, you do not need any
|
|
modifications or any extra care to write
|
|
<makevar>DESTDIR</makevar>-compliant ports.</para>
|
|
|
|
<para>The value of <makevar>PREFIX</makevar> will be set to
|
|
<makevar>LOCALBASE</makevar> (defaulting to
|
|
<filename>/usr/local</filename>). If
|
|
<makevar>USE_LINUX_PREFIX</makevar> is set,
|
|
<makevar>PREFIX</makevar> will be <makevar>LINUXBASE</makevar>
|
|
(defaulting to <filename>/compat/linux</filename>).</para>
|
|
|
|
<para>Avoiding hard-coded <filename>/usr/local</filename> paths
|
|
in the source makes the port much more flexible and able to
|
|
cater to the needs of other sites. Often, this can be
|
|
accomplished by simply replacing occurrences of
|
|
<filename>/usr/local</filename> in the port's various
|
|
<filename>Makefile</filename>s with
|
|
<literal>${PREFIX}</literal>. This variable is
|
|
automatically passed down to every stage of the build and
|
|
install processes.</para>
|
|
|
|
<para>Make sure your application is not installing things in
|
|
<filename>/usr/local</filename> instead of
|
|
<makevar>PREFIX</makevar>. A quick test for such hard-coded
|
|
paths is:</para>
|
|
|
|
<screen>&prompt.root; <userinput>make clean; make package PREFIX=/var/tmp/`make -V PORTNAME`</userinput></screen>
|
|
|
|
<para>If anything is installed outside of
|
|
<makevar>PREFIX</makevar>, the package creation process will
|
|
complain that it cannot find the files.</para>
|
|
|
|
<para>This test will not find hard-coded paths inside the
|
|
port's files, nor will it verify that
|
|
<makevar>LOCALBASE</makevar> is being used to correctly refer
|
|
to files from other ports. The temporarily-installed port in
|
|
<filename>/var/tmp/`make -V PORTNAME`</filename> should be
|
|
tested for proper operation to make sure there
|
|
are no problems with paths.</para>
|
|
|
|
<para><makevar>PREFIX</makevar> should not be set explicitly
|
|
in a port's <filename>Makefile</filename>. Users installing
|
|
the port may have set <makevar>PREFIX</makevar> to a custom
|
|
location, and the port should respect that setting.</para>
|
|
|
|
<para>Refer to programs and files from other ports with the
|
|
variables mentioned above, not explicit pathnames. For
|
|
instance, if your port requires a macro
|
|
<literal>PAGER</literal> to have the full pathname of
|
|
<command>less</command>, do not use a literal path of
|
|
<filename>/usr/local/bin/less</filename>. Instead, use
|
|
<literal>${LOCALBASE}</literal>:</para>
|
|
|
|
<programlisting>-DPAGER=\"${LOCALBASE}/bin/less\"</programlisting>
|
|
|
|
<para>The path with <makevar>LOCALBASE</makevar> is more likely
|
|
to still work if the system administrator has moved the whole
|
|
<filename>/usr/local</filename> tree somewhere else.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="testing-tinderbox">
|
|
<title>Tinderbox</title>
|
|
|
|
<para>If you are an avid ports contributor, you might want to
|
|
take a look at <application>Tinderbox</application>. It is a
|
|
powerful system for building and testing ports based on the
|
|
scripts used on <link
|
|
linkend="build-cluster">Pointyhat</link>. You can install
|
|
<application>Tinderbox</application> using <filename
|
|
role="package">ports-mgmt/tinderbox</filename> port. Be
|
|
sure to read supplied documentation since the configuration is
|
|
not trivial.</para>
|
|
|
|
<para>Visit the <ulink
|
|
url="http://tinderbox.marcuscom.com/">Tinderbox
|
|
website</ulink> for more details.</para>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="port-upgrading">
|
|
<title>Upgrading an Individual Port</title>
|
|
|
|
<para>When you notice that a port is out of date compared to the
|
|
latest version from the original authors, you should first
|
|
ensure that you have the latest port. You can find them in the
|
|
<filename>ports/ports-current</filename> directory of the &os;
|
|
FTP mirror sites. However, if you are working with more than a
|
|
few ports, you will probably find it easier to use
|
|
<application>CVSup</application> to keep your whole ports
|
|
collection up-to-date, as described in the <ulink
|
|
url="&url.books.handbook;/synching.html#CVSUP-CONFIG">Handbook</ulink>.
|
|
This will have the added benefit of tracking all the ports'
|
|
dependencies.</para>
|
|
|
|
<para>The next step is to see if there is an update already
|
|
pending. To do this, you have two options. There is a
|
|
searchable interface to the <ulink
|
|
url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
|
|
FreeBSD Problem Report (PR) database</ulink> (also known as
|
|
<literal>GNATS</literal>). Select <literal>ports</literal> in
|
|
the dropdown, and enter the name of the port.</para>
|
|
|
|
<para>However, sometimes people forget to put the name of the port
|
|
into the Synopsis field in an unambiguous fashion. In that
|
|
case, you can try the <link linkend="portsmon"> FreeBSD Ports
|
|
Monitoring System</link> (also known as
|
|
<literal>portsmon</literal>). This system attempts to classify
|
|
port PRs by portname. To search for PRs about a particular
|
|
port, use the <ulink
|
|
url="http://portsmon.FreeBSD.org/portoverview.py">
|
|
Overview of One Port</ulink>.</para>
|
|
|
|
<para>If there is no pending PR, the next step is to send an email
|
|
to the port's maintainer, as shown by <command>make
|
|
maintainer</command>. That person may already be working on
|
|
an upgrade, or have a reason to not upgrade the port right now
|
|
(because of, for example, stability problems of the new
|
|
version); you would not want to duplicate their work. Note that
|
|
unmaintained ports are listed with a maintainer of
|
|
<literal>ports@FreeBSD.org</literal>, which is just the general
|
|
ports mailing list, so sending mail there probably will not help
|
|
in this case.</para>
|
|
|
|
<para>If the maintainer asks you to do the upgrade or there is
|
|
no maintainer, then you have a chance to help out &os; by
|
|
preparing the update yourself! Please do this by using the
|
|
&man.diff.1; command in the base system.</para>
|
|
|
|
<para>To create a suitable <command>diff</command> for a single
|
|
patch, copy the file that needs patching to
|
|
<replaceable>something.orig</replaceable>, save your changes to
|
|
<replaceable>something</replaceable> and then create your
|
|
patch:</para>
|
|
|
|
<informalexample>
|
|
<screen>&prompt.user; <userinput>/usr/bin/diff something.orig something > something.diff</userinput></screen>
|
|
</informalexample>
|
|
|
|
<para>Otherwise, you should either use the <command>svn
|
|
diff</command> method (<xref linkend="svn-diff"/>) or copy the
|
|
contents of the port to an entire different directory and use
|
|
the result of the recursive &man.diff.1; output of the new and
|
|
old ports directories (e.g., if your modified port directory is
|
|
called <filename>superedit</filename> and the original is in our
|
|
tree as <filename>superedit.bak</filename>, then save the result
|
|
of <command>diff -ruN superedit.bak superedit</command>).
|
|
Either unified or context diff is fine, but port committers
|
|
generally prefer unified diffs. Note the use of the
|
|
<literal>-N</literal> option—this is the accepted way to
|
|
force diff to properly deal with the case of new files being
|
|
added or old files being deleted. Before sending us the diff,
|
|
please examine the output to make sure all the changes make
|
|
sense. (In particular, make sure you first clean out the work
|
|
directories with <command>make clean</command>).</para>
|
|
|
|
<para>To simplify common operations with patch files, you can use
|
|
<filename>/usr/ports/Tools/scripts/patchtool.py</filename>.
|
|
Before using it, please read
|
|
<filename>/usr/ports/Tools/scripts/README.patchtool</filename>.</para>
|
|
|
|
<para>If the port is unmaintained, and you are actively using
|
|
it yourself, please consider volunteering to become its
|
|
maintainer. &os; has over 4000 ports without maintainers, and
|
|
this is an area where more volunteers are always needed. (For a
|
|
detailed description of the responsibilities of maintainers,
|
|
refer to the section in the <ulink
|
|
url="&url.books.developers-handbook;/policies.html#POLICIES-MAINTAINER">
|
|
Developer's Handbook</ulink>.)</para>
|
|
|
|
<para> The best way to send us the diff is by including it via
|
|
&man.send-pr.1; (category <literal>ports</literal>). If you are
|
|
maintaining the port, be sure to put <literal>[maintainer
|
|
update]</literal> at the beginning of your synopsis line and set
|
|
the <quote>Class</quote> of your PR to
|
|
<literal>maintainer-update</literal>. Otherwise, the
|
|
<quote>Class</quote> of your PR should be
|
|
<literal>change-request</literal>. Please mention any added or
|
|
deleted files in the message, as they have to be explicitly
|
|
specified to &man.svn.1; when doing a commit. If the diff is
|
|
more than about 20KB, please compress and uuencode it;
|
|
otherwise, just include it in the PR as is.</para>
|
|
|
|
<para>Before you &man.send-pr.1;, you should review the
|
|
<ulink url="&url.articles.problem-reports;/pr-writing.html">
|
|
Writing the problem report</ulink> section in the Problem
|
|
Reports article; it contains far more information about how to
|
|
write useful problem reports.</para>
|
|
|
|
<important>
|
|
<para>If your upgrade is motivated by security concerns or a
|
|
serious fault in the currently committed port, please notify
|
|
the &a.portmgr; to request immediate rebuilding and
|
|
redistribution of your port's package. Unsuspecting users
|
|
of &man.pkg.add.1; will otherwise continue to install the
|
|
old version via <command>pkg_add -r</command> for several
|
|
weeks.</para>
|
|
</important>
|
|
|
|
<note>
|
|
<para>Once again, please use &man.diff.1; and not &man.shar.1;
|
|
to send updates to existing ports! This helps ports
|
|
committers understand exactly what is being changed.</para>
|
|
</note>
|
|
|
|
<para>Now that you have done all that, you will want to read about
|
|
how to keep up-to-date in <xref linkend="keeping-up"/>.</para>
|
|
|
|
<sect1 id="svn-diff">
|
|
<title>Using <literal>SVN</literal> to Make Patches</title>
|
|
|
|
<para>If you can, please submit a &man.svn.1 diff; they are easier to
|
|
handle than diffs between <quote>new and old</quote>
|
|
directories. Plus it is easier for you to see what you have
|
|
changed and to update your diff if something is modified in
|
|
the Ports Collection from when you started to work on it until
|
|
you submit your changes, or if the committer asks you to fix
|
|
something.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd ~/my_wrkdir</userinput> <co id="my-wrkdir"/>
|
|
&prompt.user; <userinput>svn co svn://svn.FreeBSD.org/ports/head/dns/pdnsd</userinput> <co id="svn-FreeBSD-org"/>
|
|
&prompt.user; <userinput>cd ~/my_wrkdir/pdnsd</userinput></screen>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="my-wrkdir">
|
|
|
|
<para>This can be anywhere you want, of course; building
|
|
ports is not limited to within <filename
|
|
class="directory">/usr/ports/</filename>.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="svn-FreeBSD-org">
|
|
<para><ulink url="http://svn.FreeBSD.org/">svn.FreeBSD.org</ulink>
|
|
is a public <literal>SVN</literal> server.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
<para>While in the working directory, make any changes that you
|
|
would usually make to the port. If you add or remove a file,
|
|
use <command>svn</command> to track these changes:</para>
|
|
|
|
<screen>&prompt.user; <userinput>svn add new_file</userinput>
|
|
&prompt.user; <userinput>svn remove deleted_file</userinput></screen>
|
|
|
|
<para>Make sure that you check the port using the checklist in
|
|
<xref linkend="porting-testing"/> and
|
|
<xref linkend="porting-portlint"/>.</para>
|
|
|
|
<screen>&prompt.user; <userinput>svn status</userinput>
|
|
&prompt.user; <userinput>svn update</userinput> <co id="svn-update"/></screen>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="svn-update">
|
|
<para>This will try to merge the differences between your
|
|
patch and current SVN; watch the output carefully. The
|
|
letter in front of each file name indicates what was done
|
|
with it. See <xref linkend="table-svn-up"/> for a complete
|
|
list.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
|
|
<table pgwide="1" frame="none" id="table-svn-up">
|
|
<title><literal>SVN</literal> Update File Prefixes</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry>U</entry>
|
|
<entry>The file was updated without problems.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>G</entry>
|
|
<entry>The file was updated without problems (you will
|
|
only see this when working against a remote
|
|
repository).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>M</entry>
|
|
<entry>The file had been modified, and was merged
|
|
without conflicts.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>C</entry>
|
|
<entry>The file had been modified, and was merged with
|
|
conflicts.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>If you get <literal>C</literal> as a result of
|
|
<command>svn update</command> it means something changed in
|
|
the SVN repository and &man.svn.1; was not able to merge your
|
|
local changes and those from the repository. It is always a good idea
|
|
to inspect the changes anyway, since &man.svn.1;
|
|
does not know anything about how a port should be, so it might
|
|
(and probably will) merge things that do not make sense.</para>
|
|
|
|
<para>The last step is to make a unified &man.diff.1;
|
|
of the files against SVN:</para>
|
|
|
|
<screen>&prompt.user; <userinput>svn diff > ../`basename ${PWD}`.diff</userinput></screen>
|
|
|
|
<note>
|
|
<para>Any files that have been removed should be explicitly
|
|
mentioned in the PR, because file removal may not be obvious
|
|
to the committer.</para>
|
|
</note>
|
|
|
|
<para>Send your patch following the guidelines in
|
|
<xref linkend="port-upgrading"/>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="moved-and-updating-files">
|
|
<title>The Files <filename>UPDATING</filename> and
|
|
<filename>MOVED</filename></title>
|
|
|
|
<para>If upgrading the port requires special steps like
|
|
changing configuration files or running a specific program,
|
|
you should document this in the file
|
|
<filename>/usr/ports/UPDATING</filename>. The format of
|
|
an entry in this file is as follows:</para>
|
|
|
|
<programlisting>YYYYMMDD:
|
|
AFFECTS: users of portcategory/portname
|
|
AUTHOR: Your name <Your email address>
|
|
|
|
Special instructions</programlisting>
|
|
|
|
<para>If you are including exact portmaster or portupgrading
|
|
instructions, please make sure to get the shell escaping
|
|
right.</para>
|
|
|
|
<para>The <filename>/usr/ports/MOVED</filename> file is used to
|
|
list moved or removed ports. Each line in the file is made
|
|
up of the name of the port, where the port was moved to, when,
|
|
and why. If the port was removed, the section detailing where
|
|
it was moved to can be left blank. Each section must be
|
|
separated by the <literal>|</literal> (pipe) character, like
|
|
so:</para>
|
|
|
|
<programlisting>old name|new name (blank for deleted)|date of move|reason</programlisting>
|
|
|
|
<para>The date should be entered in the form <literal>YYYY-
|
|
MM-DD</literal>. New entries should be added to the end
|
|
of the file to keep it in chronological order.</para>
|
|
|
|
<para>If a port was removed but has since been restored,
|
|
delete the line in this file that states that it was
|
|
removed.</para>
|
|
|
|
<para>The changes can be validated with
|
|
<command>Tools/scripts/MOVEDlint.awk</command>.</para>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="security">
|
|
<title>Ports Security</title>
|
|
|
|
<sect1 id="security-intro">
|
|
<title>Why Security is So Important</title>
|
|
|
|
<para>Bugs are occasionally introduced to the software.
|
|
Arguably, the most dangerous of them are those opening
|
|
security vulnerabilities. From the technical viewpoint,
|
|
such vulnerabilities are to be closed by exterminating
|
|
the bugs that caused them. However, the policies for
|
|
handling mere bugs and security vulnerabilities are
|
|
very different.</para>
|
|
|
|
<para>A typical small bug affects only those users who have
|
|
enabled some combination of options triggering the bug.
|
|
The developer will eventually release a patch followed
|
|
by a new version of the software, free of the bug, but
|
|
the majority of users will not take the trouble of upgrading
|
|
immediately because the bug has never vexed them. A
|
|
critical bug that may cause data loss represents a graver
|
|
issue. Nevertheless, prudent users know that a lot of
|
|
possible accidents, besides software bugs, are likely to
|
|
lead to data loss, and so they make backups of important
|
|
data; in addition, a critical bug will be discovered
|
|
really soon.</para>
|
|
|
|
<para>A security vulnerability is all different. First,
|
|
it may remain unnoticed for years because often it does
|
|
not cause software malfunction. Second, a malicious party
|
|
can use it to gain unauthorized access to a vulnerable
|
|
system, to destroy or alter sensitive data; and in the
|
|
worst case the user will not even notice the harm caused.
|
|
Third, exposing a vulnerable system often assists attackers
|
|
to break into other systems that could not be compromised
|
|
otherwise. Therefore closing a vulnerability alone is
|
|
not enough: the audience should be notified of it in most
|
|
clear and comprehensive manner, which will allow to
|
|
evaluate the danger and take appropriate actions.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="security-fix">
|
|
<title>Fixing Security Vulnerabilities</title>
|
|
|
|
<para>While on the subject of ports and packages, a security
|
|
vulnerability may initially appear in the original
|
|
distribution or in the port files. In the former case, the
|
|
original software developer is likely to release a patch or a
|
|
new version instantly, and you will only need to update the
|
|
port promptly with respect to the author's fix. If the fix is
|
|
delayed for some reason, you should either <link
|
|
linkend="dads-noinstall">mark the port as
|
|
<makevar>FORBIDDEN</makevar></link> or introduce a patch file
|
|
of your own to the port. In the case of a vulnerable port,
|
|
just fix the port as soon as possible. In either case, <link
|
|
linkend="port-upgrading">the standard procedure for
|
|
submitting your change</link> should be followed unless you
|
|
have rights to commit it directly to the ports tree.</para>
|
|
|
|
<important>
|
|
<para>Being a ports committer is not enough to commit to
|
|
an arbitrary port. Remember that ports usually have
|
|
maintainers, whom you should respect.</para>
|
|
</important>
|
|
|
|
<para>Please make sure that the port's revision is bumped
|
|
as soon as the vulnerability has been closed.
|
|
That is how the users who upgrade installed packages
|
|
on a regular basis will see they need to run an update.
|
|
Besides, a new package will be built and distributed
|
|
over FTP and WWW mirrors, replacing the vulnerable one.
|
|
<makevar>PORTREVISION</makevar> should be bumped unless
|
|
<makevar>PORTVERSION</makevar> has changed in the course
|
|
of correcting the vulnerability. That is you should
|
|
bump <makevar>PORTREVISION</makevar> if you have added a
|
|
patch file to the port, but you should not if you have updated
|
|
the port to the latest software version and thus already
|
|
touched <makevar>PORTVERSION</makevar>. Please refer to the
|
|
<link linkend="makefile-naming-revepoch">corresponding
|
|
section</link> for more information.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="security-notify">
|
|
<title>Keeping the Community Informed</title>
|
|
|
|
<sect2 id="security-notify-vuxml-db">
|
|
<title>The VuXML Database</title>
|
|
|
|
<para>A very important and urgent step to take as early after
|
|
a security vulnerability is discovered as possible is to
|
|
notify the community of port users about the jeopardy. Such
|
|
notification serves two purposes. First, should the danger
|
|
be really severe it will be wise to apply an instant
|
|
workaround. E.g., stop the affected network service or even
|
|
deinstall the port completely until the vulnerability is
|
|
closed. Second, a lot of users tend to upgrade installed
|
|
packages only occasionally. They will know from the
|
|
notification that they <emphasis>must</emphasis> update the
|
|
package without delay as soon as a corrected version is
|
|
available.</para>
|
|
|
|
<para>Given the huge number of ports in the tree
|
|
a security advisory cannot be issued on each incident
|
|
without creating a flood and losing the attention of
|
|
the audience when it comes to really serious
|
|
matters. Therefore security vulnerabilities found in
|
|
ports are recorded in <ulink
|
|
url="http://vuxml.freebsd.org/">the FreeBSD VuXML
|
|
database</ulink>. The Security Officer Team members
|
|
also monitor it for issues requiring their
|
|
intervention.</para>
|
|
|
|
<para>If you have committer rights you can update the VuXML
|
|
database by yourself. So you will both help the Security
|
|
Officer Team and deliver the crucial information to the
|
|
community earlier. However, if you are not a committer,
|
|
or you believe you have found an exceptionally severe
|
|
vulnerability please do not hesitate to
|
|
contact the Security Officer Team directly as described
|
|
on the <ulink
|
|
url="http://www.freebsd.org/security/#how">FreeBSD
|
|
Security Information</ulink> page.</para>
|
|
|
|
<para>The VuXML database is an
|
|
XML document. Its source file <filename>vuln.xml</filename>
|
|
is kept right inside the port <filename
|
|
role="package">security/vuxml</filename>. Therefore
|
|
the file's full pathname will be
|
|
<filename><envar>PORTSDIR</envar>/security/vuxml/vuln.xml</filename>.
|
|
Each time you discover a security vulnerability in a
|
|
port please add an entry for it to that file.
|
|
Until you are familiar with VuXML, the best thing you can
|
|
do is to find an existing entry fitting your case, then copy
|
|
it and use it as a template.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="security-notify-vuxml-intro">
|
|
<title>A Short Introduction to VuXML</title>
|
|
|
|
<para>The full-blown XML format is complex, and far beyond the
|
|
scope of this book. However, to gain basic insight on the
|
|
structure of a VuXML entry you need only the notion of tags.
|
|
XML tag names are enclosed in angle brackets. Each opening
|
|
<tag> must have a matching closing </tag>. Tags
|
|
may be nested. If nesting, the inner tags must be closed
|
|
before the outer ones. There is a hierarchy of tags, i.e.
|
|
more complex rules of nesting them. Sounds very similar to
|
|
HTML, doesn't it? The major difference is that XML is
|
|
e<emphasis>X</emphasis>tensible, i.e., based on defining
|
|
custom tags. Due to its intrinsic structure XML puts
|
|
otherwise amorphous data into shape. VuXML is particularly
|
|
tailored to mark up descriptions of security
|
|
vulnerabilities.</para>
|
|
|
|
<para>Now let's consider a realistic VuXML entry:</para>
|
|
|
|
<programlisting><vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <co id="co-vx-vid"/>
|
|
<topic>Several vulnerabilities found in Foo</topic> <co id="co-vx-top"/>
|
|
<affects>
|
|
<package>
|
|
<name>foo</name> <co id="co-vx-nam"/>
|
|
<name>foo-devel</name>
|
|
<name>ja-foo</name>
|
|
<range><ge>1.6</ge><lt>1.9</lt></range> <co id="co-vx-rng"/>
|
|
<range><ge>2.*</ge><lt>2.4_1</lt></range>
|
|
<range><eq>3.0b1</eq></range>
|
|
</package>
|
|
<package>
|
|
<name>openfoo</name> <co id="co-vx-nm2"/>
|
|
<range><lt>1.10_7</lt></range> <co id="co-vx-epo"/>
|
|
<range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
|
|
</package>
|
|
</affects>
|
|
<description>
|
|
<body xmlns="http://www.w3.org/1999/xhtml">
|
|
<p>J. Random Hacker reports:</p> <co id="co-vx-bdy"/>
|
|
<blockquote
|
|
cite="http://j.r.hacker.com/advisories/1">
|
|
<p>Several issues in the Foo software may be exploited
|
|
via carefully crafted QUUX requests. These requests will
|
|
permit the injection of Bar code, mumble theft, and the
|
|
readability of the Foo administrator account.</p>
|
|
</blockquote>
|
|
</body>
|
|
</description>
|
|
<references> <co id="co-vx-ref"/>
|
|
<freebsdsa>SA-10:75.foo</freebsdsa> <co id="co-vx-fsa"/>
|
|
<freebsdpr>ports/987654</freebsdpr> <co id="co-vx-fpr"/>
|
|
<cvename>CAN-2010-0201</cvename> <co id="co-vx-cve"/>
|
|
<cvename>CAN-2010-0466</cvename>
|
|
<bid>96298</bid> <co id="co-vx-bid"/>
|
|
<certsa>CA-2010-99</certsa> <co id="co-vx-cts"/>
|
|
<certvu>740169</certvu> <co id="co-vx-ctv"/>
|
|
<uscertsa>SA10-99A</uscertsa> <co id="co-vx-ucs"/>
|
|
<uscertta>SA10-99A</uscertta> <co id="co-vx-uct"/>
|
|
<mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <co id="co-vx-mls"/>
|
|
<url>http://j.r.hacker.com/advisories/1</url> <co id="co-vx-url"/>
|
|
</references>
|
|
<dates>
|
|
<discovery>2010-05-25</discovery> <co id="co-vx-dsc"/>
|
|
<entry>2010-07-13</entry> <co id="co-vx-ent"/>
|
|
<modified>2010-09-17</modified> <co id="co-vx-mod"/>
|
|
</dates>
|
|
</vuln></programlisting>
|
|
|
|
<para>The tag names are supposed to be self-explanatory
|
|
so we shall take a closer look only at fields you will need
|
|
to fill in by yourself:</para>
|
|
|
|
<calloutlist>
|
|
<callout arearefs="co-vx-vid">
|
|
<para>This is the top-level tag of a VuXML entry. It has
|
|
a mandatory attribute, <literal>vid</literal>,
|
|
specifying a universally unique identifier (UUID) for
|
|
this entry (in quotes). You should generate a UUID for
|
|
each new VuXML entry (and do not forget to substitute it
|
|
for the template UUID unless you are writing the entry
|
|
from scratch). You can use &man.uuidgen.1; to generate
|
|
a VuXML UUID.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-top">
|
|
<para>This is a one-line description of the issue
|
|
found.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-nam">
|
|
<para>The names of packages affected are listed there.
|
|
Multiple names can be given since several packages may
|
|
be based on a single master port or software product.
|
|
This may include stable and development branches,
|
|
localized versions, and slave ports featuring different
|
|
choices of important build-time configuration
|
|
options.</para>
|
|
|
|
<important>
|
|
<para>It is your responsibility to find all such related
|
|
packages when writing a VuXML entry. Keep in mind
|
|
that <literal>make search name=foo</literal> is your
|
|
friend. The primary points to look for are as
|
|
follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>the <filename>foo-devel</filename> variant
|
|
for a <filename>foo</filename> port;</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>other variants with a suffix like
|
|
<literal>-a4</literal> (for print-related
|
|
packages), <literal>-without-gui</literal> (for
|
|
packages with X support disabled), or
|
|
similar;</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>jp-</literal>,
|
|
<literal>ru-</literal>, <literal>zh-</literal>,
|
|
and other possible localized variants in the
|
|
corresponding national categories of the ports
|
|
collection.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</important>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-rng">
|
|
<para>Affected versions of the package(s) are specified
|
|
there as one or more ranges using a combination of
|
|
<literal><lt></literal>,
|
|
<literal><le></literal>,
|
|
<literal><eq></literal>,
|
|
<literal><ge></literal>, and
|
|
<literal><gt></literal> elements. The version
|
|
ranges given should not overlap.</para>
|
|
|
|
<para>In a range specification, <literal>*</literal>
|
|
(asterisk) denotes the smallest version number. In
|
|
particular, <literal>2.*</literal> is less than
|
|
<literal>2.a</literal>. Therefore an asterisk may be
|
|
used for a range to match all possible
|
|
<literal>alpha</literal>, <literal>beta</literal>, and
|
|
<literal>RC</literal> versions. For instance,
|
|
<literal><ge>2.*</ge><lt>3.*</lt></literal>
|
|
will selectively match every <literal>2.x</literal>
|
|
version while
|
|
<literal><ge>2.0</ge><lt>3.0</lt></literal>
|
|
will not since the latter misses
|
|
<literal>2.r3</literal> and matches
|
|
<literal>3.b</literal>.</para>
|
|
|
|
<para>The above example specifies that affected are
|
|
versions from <literal>1.6</literal> to
|
|
<literal>1.9</literal> inclusive, versions
|
|
<literal>2.x</literal> before <literal>2.4_1</literal>,
|
|
and version <literal>3.0b1</literal>.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-nm2">
|
|
<para>Several related package groups (essentially, ports)
|
|
can be listed in the <literal><affected></literal>
|
|
section. This can be used if several software products
|
|
(say FooBar, FreeBar and OpenBar) grow from the same
|
|
code base and still share its bugs and vulnerabilities.
|
|
Note the difference from listing multiple names within a
|
|
single <package> section.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-epo">
|
|
<para>The version ranges should allow for
|
|
<makevar>PORTEPOCH</makevar> and
|
|
<makevar>PORTREVISION</makevar> if applicable. Please
|
|
remember that according to the collation rules, a
|
|
version with a non-zero <makevar>PORTEPOCH</makevar> is
|
|
greater than any version without
|
|
<makevar>PORTEPOCH</makevar>, e.g.,
|
|
<literal>3.0,1</literal> is greater than
|
|
<literal>3.1</literal> or even than
|
|
<literal>8.9</literal>.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-bdy">
|
|
<para>This is a summary of the issue. XHTML is used in
|
|
this field. At least enclosing
|
|
<literal><p></literal> and
|
|
<literal></p></literal> should appear. More
|
|
complex mark-up may be used, but only for the sake of
|
|
accuracy and clarity: No eye candy please.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-ref">
|
|
<para>This section contains references to relevant
|
|
documents. As many references as apply are
|
|
encouraged.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-fsa">
|
|
<para>This is a <ulink
|
|
url="http://www.freebsd.org/security/#adv">FreeBSD
|
|
security advisory</ulink>.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-fpr">
|
|
<para>This is a <ulink
|
|
url="http://www.freebsd.org/support.html#gnats">FreeBSD
|
|
problem report</ulink>.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-cve">
|
|
<para>This is a <ulink
|
|
url="http://www.cve.mitre.org/">MITRE
|
|
CVE</ulink> identifier.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-bid">
|
|
<para>This is a <ulink
|
|
url="http://www.securityfocus.com/bid">SecurityFocus
|
|
Bug ID</ulink>.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-cts">
|
|
<para>This is a
|
|
<ulink url="http://www.cert.org/">US-CERT</ulink>
|
|
security advisory.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-ctv">
|
|
<para>This is a <ulink
|
|
url="http://www.cert.org/">US-CERT</ulink>
|
|
vulnerability note.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-ucs">
|
|
<para>This is a <ulink
|
|
url="http://www.cert.org/">US-CERT</ulink>
|
|
Cyber Security Alert.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-uct">
|
|
<para>This is a <ulink
|
|
url="http://www.cert.org/">US-CERT</ulink>
|
|
Technical Cyber Security Alert.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-mls">
|
|
<para>This is a URL to an archived posting in a mailing
|
|
list. The attribute <literal>msgid</literal> is
|
|
optional and may specify the message ID of the
|
|
posting.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-url">
|
|
<para>This is a generic URL. It should be used only if
|
|
none of the other reference categories apply.</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-dsc">
|
|
<para>This is the date when the issue was disclosed
|
|
(<replaceable>YYYY-MM-DD</replaceable>).</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-ent">
|
|
<para>This is the date when the entry was added
|
|
(<replaceable>YYYY-MM-DD</replaceable>).</para>
|
|
</callout>
|
|
|
|
<callout arearefs="co-vx-mod">
|
|
<para>This is the date when any information in the entry
|
|
was last modified
|
|
(<replaceable>YYYY-MM-DD</replaceable>). New entries
|
|
must not include this field. It should be added upon
|
|
editing an existing entry.</para>
|
|
</callout>
|
|
</calloutlist>
|
|
</sect2>
|
|
|
|
<sect2 id="security-notify-vuxml-testing">
|
|
<title>Testing Your Changes to the VuXML Database</title>
|
|
|
|
<para>Assume you just wrote or filled in an entry for a
|
|
vulnerability in the package <literal>clamav</literal> that
|
|
has been fixed in version <literal>0.65_7</literal>.</para>
|
|
|
|
<para>As a prerequisite, you need to
|
|
<emphasis>install</emphasis> fresh versions of the ports
|
|
<filename role="package">ports-mgmt/portaudit</filename>,
|
|
<filename role="package">ports-mgmt/portaudit-db</filename>,
|
|
and <filename
|
|
role="package">security/vuxml</filename>.</para>
|
|
|
|
<note>
|
|
<para>To run <command>packaudit</command> you must have
|
|
permission to write to its
|
|
<filename><makevar>DATABASEDIR</makevar></filename>,
|
|
typically <filename>/var/db/portaudit</filename>.</para>
|
|
|
|
<para>To use a different directory set the
|
|
<filename><makevar>DATABASEDIR</makevar></filename>
|
|
environment variable to a different location.</para>
|
|
|
|
<para>If you are working in a directory other than
|
|
<filename>${PORTSDIR}/security/vuxml</filename> set the
|
|
<filename><makevar>VUXMLDIR</makevar></filename>
|
|
environment variable to the directory where
|
|
<filename>vuln.xml</filename> is located.</para>
|
|
</note>
|
|
|
|
<para>First, check whether there already is an entry for this
|
|
vulnerability. If there were such an entry, it would match
|
|
the previous version of the package,
|
|
<literal>0.65_6</literal>:</para>
|
|
|
|
<screen>&prompt.user; <userinput>packaudit</userinput>
|
|
&prompt.user; <userinput>portaudit clamav-0.65_6</userinput></screen>
|
|
|
|
<para>If there is none found, you have the green light to add
|
|
a new entry for this vulnerability.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd ${PORTSDIR}/security/vuxml</userinput>
|
|
&prompt.user; <userinput>make newentry</userinput></screen>
|
|
|
|
<para>When you are done verify its syntax and
|
|
formatting.</para>
|
|
|
|
<screen>&prompt.user; <userinput>make validate</userinput></screen>
|
|
|
|
<note>
|
|
<para>You will need at least one of the following packages
|
|
installed: <filename
|
|
role="package">textproc/libxml2</filename>, <filename
|
|
role="package">textproc/jade</filename>.</para>
|
|
</note>
|
|
|
|
<para>Now rebuild the <command>portaudit</command> database
|
|
from the VuXML file:</para>
|
|
|
|
<screen>&prompt.user; <userinput>packaudit</userinput></screen>
|
|
|
|
<para>To verify that the <literal><affected></literal>
|
|
section of your entry will match correct package(s), issue
|
|
the following command:</para>
|
|
|
|
<screen>&prompt.user; <userinput>portaudit -f /usr/ports/INDEX -r <replaceable>uuid</replaceable></userinput></screen>
|
|
|
|
<note>
|
|
<para>Please refer to &man.portaudit.1; for better
|
|
understanding of the command syntax.</para>
|
|
</note>
|
|
|
|
<para>Make sure that your entry produces no spurious matches
|
|
in the output.</para>
|
|
|
|
<para>Now check whether the right package versions are matched
|
|
by your entry:</para>
|
|
|
|
<screen>&prompt.user; <userinput>portaudit clamav-0.65_6 clamav-0.65_7</userinput>
|
|
Affected package: clamav-0.65_6 (matched by clamav<0.65_7)
|
|
Type of problem: clamav remote denial-of-service.
|
|
Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html>
|
|
|
|
1 problem(s) found.</screen>
|
|
|
|
<para>The former version should match while the
|
|
latter one should not.</para>
|
|
|
|
<para>Finally, verify whether the web page generated from the
|
|
VuXML database looks like expected:</para>
|
|
|
|
<screen>&prompt.user; <userinput>mkdir -p ~/public_html/portaudit</userinput>
|
|
&prompt.user; <userinput>packaudit</userinput>
|
|
&prompt.user; <userinput>lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html</userinput></screen>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<chapter id="porting-dads">
|
|
<title>Dos and Don'ts</title>
|
|
|
|
<sect1 id="dads-intro">
|
|
<title>Introduction</title>
|
|
|
|
<para>Here is a list of common dos and don'ts that you encounter
|
|
during the porting process. You should check your own port
|
|
against this list, but you can also check ports in the <ulink
|
|
url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">PR
|
|
database</ulink> that others have submitted. Submit any
|
|
comments on ports you check as described in <ulink
|
|
url="&url.articles.contributing;/contrib-how.html#CONTRIB-GENERAL">Bug
|
|
Reports and General Commentary</ulink>. Checking ports in the
|
|
PR database will both make it faster for us to commit them,
|
|
and prove that you know what you are doing.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-wrkdir">
|
|
<title><makevar>WRKDIR</makevar></title>
|
|
|
|
<para>Do not write anything to files outside
|
|
<makevar>WRKDIR</makevar>. <makevar>WRKDIR</makevar> is the
|
|
only place that is guaranteed to be writable during the port
|
|
build (see <ulink
|
|
url="&url.books.handbook;/ports-using.html#PORTS-CD">
|
|
installing ports from a CDROM</ulink> for an example of
|
|
building ports from a read-only tree). If you need to modify
|
|
one of the
|
|
<filename>pkg-<replaceable>*</replaceable></filename> files,
|
|
do so by <link
|
|
linkend="porting-pkgfiles">redefining a variable</link>, not
|
|
by writing over it.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-wrkdirprefix">
|
|
<title><makevar>WRKDIRPREFIX</makevar></title>
|
|
|
|
<para>Make sure your port honors
|
|
<makevar>WRKDIRPREFIX</makevar>. Most ports do not have to
|
|
worry about this. In particular, if you are referring to a
|
|
<makevar>WRKDIR</makevar> of another port, note that the
|
|
correct location is
|
|
<filename><makevar>WRKDIRPREFIX</makevar><makevar>PORTSDIR</makevar>/<replaceable>subdir</replaceable>/<replaceable>name</replaceable>/work</filename>
|
|
not
|
|
<filename><makevar>PORTSDIR</makevar>/<replaceable>subdir</replaceable>/<replaceable>name</replaceable>/work</filename>
|
|
or
|
|
<filename><makevar>.CURDIR</makevar>/../../<replaceable>subdir</replaceable>/<replaceable>name</replaceable>/work</filename>
|
|
or some such.</para>
|
|
|
|
<para>Also, if you are defining <makevar>WRKDIR</makevar>
|
|
yourself, make sure you prepend
|
|
<literal>${WRKDIRPREFIX}${.CURDIR}</literal> in
|
|
the front.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="porting-versions">
|
|
<title>Differentiating Operating Systems and OS Versions</title>
|
|
|
|
<para>You may come across code that needs modifications or
|
|
conditional compilation based upon what version of Unix it is
|
|
running under. If you need to make such changes to the code
|
|
for conditional compilation, make sure you make the changes as
|
|
general as possible so that we can back-port code to older
|
|
FreeBSD systems and cross-port to other BSD systems such as
|
|
4.4BSD from CSRG, BSD/386, 386BSD, NetBSD, and OpenBSD.</para>
|
|
|
|
<para>The preferred way to tell 4.3BSD/Reno (1990) and newer
|
|
versions of the BSD code apart is by using the
|
|
<literal>BSD</literal> macro defined in <ulink
|
|
url="http://svnweb.freebsd.org/base/head/sys/sys/param.h?view=markup">sys/param.h</ulink>.
|
|
Hopefully that file is already included; if not, add the
|
|
code:</para>
|
|
|
|
<programlisting>#if (defined(__unix__) || defined(unix)) && !defined(USG)
|
|
#include <sys/param.h>
|
|
#endif</programlisting>
|
|
|
|
<para>to the proper place in the <filename>.c</filename> file.
|
|
We believe that every system that defines these two symbols
|
|
has <filename>sys/param.h</filename>. If you find a system
|
|
that does not, we would like to know. Please send mail to the
|
|
&a.ports;.</para>
|
|
|
|
<para>Another way is to use the GNU Autoconf style of doing
|
|
this:</para>
|
|
|
|
<programlisting>#ifdef HAVE_SYS_PARAM_H
|
|
#include <sys/param.h>
|
|
#endif</programlisting>
|
|
|
|
<para>Do not forget to add <literal>-DHAVE_SYS_PARAM_H</literal>
|
|
to the <makevar>CFLAGS</makevar> in the
|
|
<filename>Makefile</filename> for this method.</para>
|
|
|
|
<para>Once you have <filename>sys/param.h</filename> included,
|
|
you may use:</para>
|
|
|
|
<programlisting>#if (defined(BSD) && (BSD >= 199103))</programlisting>
|
|
|
|
<para>to detect if the code is being compiled on a 4.3 Net2 code
|
|
base or newer (e.g., FreeBSD 1.x, 4.3/Reno, NetBSD 0.9,
|
|
386BSD, BSD/386 1.1 and below).</para>
|
|
|
|
<para>Use:</para>
|
|
|
|
<programlisting>#if (defined(BSD) && (BSD >= 199306))</programlisting>
|
|
|
|
<para>to detect if the code is being compiled on a 4.4 code base
|
|
or newer (e.g., FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or
|
|
above).</para>
|
|
|
|
<para>The value of the <literal>BSD</literal> macro is
|
|
<literal>199506</literal> for the 4.4BSD-Lite2 code base.
|
|
This is stated for informational purposes only. It should not
|
|
be used to distinguish between versions of FreeBSD based only
|
|
on 4.4-Lite versus versions that have merged in changes from
|
|
4.4-Lite2. The <literal>__FreeBSD__</literal> macro should be
|
|
used instead.</para>
|
|
|
|
<para>Use sparingly:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>__FreeBSD__</literal> is defined in all
|
|
versions of FreeBSD. Use it if the change you are making
|
|
<emphasis>only</emphasis> affects FreeBSD. Porting
|
|
gotchas like the use of <literal>sys_errlist[]</literal>
|
|
versus <function>strerror()</function> are Berkeley-isms,
|
|
not FreeBSD changes.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In FreeBSD 2.x, <literal>__FreeBSD__</literal> is
|
|
defined to be <literal>2</literal>. In earlier versions,
|
|
it is <literal>1</literal>. Later versions always bump it
|
|
to match their major version number.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you need to tell the difference between a FreeBSD
|
|
1.x system and a FreeBSD 2.x or above system, usually the
|
|
right answer is to use the <literal>BSD</literal> macros
|
|
described above. If there actually is a FreeBSD specific
|
|
change (such as special shared library options when using
|
|
<command>ld</command>) then it is OK to use
|
|
<literal>__FreeBSD__</literal> and <literal>#if
|
|
__FreeBSD__ > 1</literal> to detect a FreeBSD 2.x and
|
|
later system. If you need more granularity in detecting
|
|
FreeBSD systems since 2.0-RELEASE you can use the
|
|
following:</para>
|
|
|
|
<programlisting>#if __FreeBSD__ >= 2
|
|
#include <osreldate.h>
|
|
# if __FreeBSD_version >= 199504
|
|
/* 2.0.5+ release specific code here */
|
|
# endif
|
|
#endif</programlisting>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>In the hundreds of ports that have been done, there have
|
|
only been one or two cases where
|
|
<literal>__FreeBSD__</literal> should have been used. Just
|
|
because an earlier port screwed up and used it in the wrong
|
|
place does not mean you should do so too.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="freebsd-versions">
|
|
<title><literal>__FreeBSD_version</literal> Values</title>
|
|
|
|
<para>Here is a convenient list of
|
|
<literal>__FreeBSD_version</literal> values as defined in
|
|
<ulink
|
|
url="http://svnweb.FreeBSD.org/base/head/sys/sys/param.h?view=markup">sys/param.h</ulink>:</para>
|
|
|
|
<table frame="none">
|
|
<title><literal>__FreeBSD_version</literal> Values</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Value</entry>
|
|
<entry>Date</entry>
|
|
<entry>Release</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>119411</entry>
|
|
<entry></entry>
|
|
<entry>2.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199501, 199503</entry>
|
|
<entry>March 19, 1995</entry>
|
|
<entry>2.1-CURRENT</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199504</entry>
|
|
<entry>April 9, 1995</entry>
|
|
<entry>2.0.5-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199508</entry>
|
|
<entry>August 26, 1995</entry>
|
|
<entry>2.2-CURRENT before 2.1</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199511</entry>
|
|
<entry>November 10, 1995</entry>
|
|
<entry>2.1.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199512</entry>
|
|
<entry>November 10, 1995</entry>
|
|
<entry>2.2-CURRENT before 2.1.5</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199607</entry>
|
|
<entry>July 10, 1996</entry>
|
|
<entry>2.1.5-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199608</entry>
|
|
<entry>July 12, 1996</entry>
|
|
<entry>2.2-CURRENT before 2.1.6</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199612</entry>
|
|
<entry>November 15, 1996</entry>
|
|
<entry>2.1.6-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>199612</entry>
|
|
<entry></entry>
|
|
<entry>2.1.7-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>220000</entry>
|
|
<entry>February 19, 1997</entry>
|
|
<entry>2.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(not changed)</entry>
|
|
<entry></entry>
|
|
<entry>2.2.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(not changed)</entry>
|
|
<entry></entry>
|
|
<entry>2.2-STABLE after 2.2.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>221001</entry>
|
|
<entry>April 15, 1997</entry>
|
|
<entry>2.2-STABLE after texinfo-3.9</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>221002</entry>
|
|
<entry>April 30, 1997</entry>
|
|
<entry>2.2-STABLE after top</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>222000</entry>
|
|
<entry>May 16, 1997</entry>
|
|
<entry>2.2.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>222001</entry>
|
|
<entry>May 19, 1997</entry>
|
|
<entry>2.2-STABLE after 2.2.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>225000</entry>
|
|
<entry>October 2, 1997</entry>
|
|
<entry>2.2.5-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>225001</entry>
|
|
<entry>November 20, 1997</entry>
|
|
<entry>2.2-STABLE after 2.2.5-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>225002</entry>
|
|
<entry>December 27, 1997</entry>
|
|
<entry>2.2-STABLE after ldconfig -R merge</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>226000</entry>
|
|
<entry>March 24, 1998</entry>
|
|
<entry>2.2.6-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>227000</entry>
|
|
<entry>July 21, 1998</entry>
|
|
<entry>2.2.7-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>227001</entry>
|
|
<entry>July 21, 1998</entry>
|
|
<entry>2.2-STABLE after 2.2.7-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>227002</entry>
|
|
<entry>September 19, 1998</entry>
|
|
<entry>2.2-STABLE after &man.semctl.2; change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>228000</entry>
|
|
<entry>November 29, 1998</entry>
|
|
<entry>2.2.8-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>228001</entry>
|
|
<entry>November 29, 1998</entry>
|
|
<entry>2.2-STABLE after 2.2.8-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300000</entry>
|
|
<entry>February 19, 1996</entry>
|
|
<entry>3.0-CURRENT before &man.mount.2; change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300001</entry>
|
|
<entry>September 24, 1997</entry>
|
|
<entry>3.0-CURRENT after &man.mount.2; change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300002</entry>
|
|
<entry>June 2, 1998</entry>
|
|
<entry>3.0-CURRENT after &man.semctl.2; change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300003</entry>
|
|
<entry>June 7, 1998</entry>
|
|
<entry>3.0-CURRENT after ioctl arg changes</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300004</entry>
|
|
<entry>September 3, 1998</entry>
|
|
<entry>3.0-CURRENT after ELF conversion</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300005</entry>
|
|
<entry>October 16, 1998</entry>
|
|
<entry>3.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300006</entry>
|
|
<entry>October 16, 1998</entry>
|
|
<entry>3.0-CURRENT after 3.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>300007</entry>
|
|
<entry>January 22, 1999</entry>
|
|
<entry>3.0-STABLE after 3/4 branch</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>310000</entry>
|
|
<entry>February 9, 1999</entry>
|
|
<entry>3.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>310001</entry>
|
|
<entry>March 27, 1999</entry>
|
|
<entry>3.1-STABLE after 3.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>310002</entry>
|
|
<entry>April 14, 1999</entry>
|
|
<entry>3.1-STABLE after C++ constructor/destructor order
|
|
change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>320000</entry>
|
|
<entry></entry>
|
|
<entry>3.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>320001</entry>
|
|
<entry>May 8, 1999</entry>
|
|
<entry>3.2-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>320002</entry>
|
|
<entry>August 29, 1999</entry>
|
|
<entry>3.2-STABLE after binary-incompatible IPFW and
|
|
socket changes</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>330000</entry>
|
|
<entry>September 2, 1999</entry>
|
|
<entry>3.3-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>330001</entry>
|
|
<entry>September 16, 1999</entry>
|
|
<entry>3.3-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>330002</entry>
|
|
<entry>November 24, 1999</entry>
|
|
<entry>3.3-STABLE after adding &man.mkstemp.3;
|
|
to libc</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>340000</entry>
|
|
<entry>December 5, 1999</entry>
|
|
<entry>3.4-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>340001</entry>
|
|
<entry>December 17, 1999</entry>
|
|
<entry>3.4-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>350000</entry>
|
|
<entry>June 20, 2000</entry>
|
|
<entry>3.5-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>350001</entry>
|
|
<entry>July 12, 2000</entry>
|
|
<entry>3.5-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400000</entry>
|
|
<entry>January 22, 1999</entry>
|
|
<entry>4.0-CURRENT after 3.4 branch</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400001</entry>
|
|
<entry>February 20, 1999</entry>
|
|
<entry>4.0-CURRENT after change in dynamic linker
|
|
handling</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400002</entry>
|
|
<entry>March 13, 1999</entry>
|
|
<entry>4.0-CURRENT after C++ constructor/destructor
|
|
order change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400003</entry>
|
|
<entry>March 27, 1999</entry>
|
|
<entry>4.0-CURRENT after functioning
|
|
&man.dladdr.3;</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400004</entry>
|
|
<entry>April 5, 1999</entry>
|
|
<entry>4.0-CURRENT after __deregister_frame_info dynamic
|
|
linker bug fix (also 4.0-CURRENT after EGCS 1.1.2
|
|
integration)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400005</entry>
|
|
<entry>April 27, 1999</entry>
|
|
<entry>4.0-CURRENT after &man.suser.9; API change
|
|
(also 4.0-CURRENT after newbus)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400006</entry>
|
|
<entry>May 31, 1999</entry>
|
|
<entry>4.0-CURRENT after cdevsw registration
|
|
change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400007</entry>
|
|
<entry>June 17, 1999</entry>
|
|
<entry>4.0-CURRENT after the addition of so_cred for
|
|
socket level credentials</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400008</entry>
|
|
<entry>June 20, 1999</entry>
|
|
<entry>4.0-CURRENT after the addition of a poll syscall
|
|
wrapper to libc_r</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400009</entry>
|
|
<entry>July 20, 1999</entry>
|
|
<entry>4.0-CURRENT after the change of the kernel's
|
|
<literal>dev_t</literal> type to <literal>struct
|
|
specinfo</literal> pointer</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400010</entry>
|
|
<entry>September 25, 1999</entry>
|
|
<entry>4.0-CURRENT after fixing a hole
|
|
in &man.jail.2;</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400011</entry>
|
|
<entry>September 29, 1999</entry>
|
|
<entry>4.0-CURRENT after the <literal>sigset_t</literal>
|
|
datatype change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400012</entry>
|
|
<entry>November 15, 1999</entry>
|
|
<entry>4.0-CURRENT after the cutover to the GCC 2.95.2
|
|
compiler</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400013</entry>
|
|
<entry>December 4, 1999</entry>
|
|
<entry>4.0-CURRENT after adding pluggable linux-mode
|
|
ioctl handlers</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400014</entry>
|
|
<entry>January 18, 2000</entry>
|
|
<entry>4.0-CURRENT after importing OpenSSL</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400015</entry>
|
|
<entry>January 27, 2000</entry>
|
|
<entry>4.0-CURRENT after the C++ ABI change in GCC
|
|
2.95.2 from -fvtable-thunks to -fno-vtable-thunks by
|
|
default</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400016</entry>
|
|
<entry>February 27, 2000</entry>
|
|
<entry>4.0-CURRENT after importing OpenSSH</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400017</entry>
|
|
<entry>March 13, 2000</entry>
|
|
<entry>4.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400018</entry>
|
|
<entry>March 17, 2000</entry>
|
|
<entry>4.0-STABLE after 4.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400019</entry>
|
|
<entry>May 5, 2000</entry>
|
|
<entry>4.0-STABLE after the introduction of delayed
|
|
checksums.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400020</entry>
|
|
<entry>June 4, 2000</entry>
|
|
<entry>4.0-STABLE after merging libxpg4 code into
|
|
libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>400021</entry>
|
|
<entry>July 8, 2000</entry>
|
|
<entry>4.0-STABLE after upgrading Binutils to 2.10.0,
|
|
ELF branding changes, and tcsh in the base
|
|
system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>410000</entry>
|
|
<entry>July 14, 2000</entry>
|
|
<entry>4.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>410001</entry>
|
|
<entry>July 29, 2000</entry>
|
|
<entry>4.1-STABLE after 4.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>410002</entry>
|
|
<entry>September 16, 2000</entry>
|
|
<entry>4.1-STABLE after &man.setproctitle.3; moved from
|
|
libutil to libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>411000</entry>
|
|
<entry>September 25, 2000</entry>
|
|
<entry>4.1.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>411001</entry>
|
|
<entry></entry>
|
|
<entry>4.1.1-STABLE after 4.1.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>420000</entry>
|
|
<entry>October 31, 2000</entry>
|
|
<entry>4.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>420001</entry>
|
|
<entry>January 10, 2001</entry>
|
|
<entry>4.2-STABLE after combining libgcc.a and
|
|
libgcc_r.a, and associated GCC linkage
|
|
changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>430000</entry>
|
|
<entry>March 6, 2001</entry>
|
|
<entry>4.3-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>430001</entry>
|
|
<entry>May 18, 2001</entry>
|
|
<entry>4.3-STABLE after wint_t introduction.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>430002</entry>
|
|
<entry>July 22, 2001</entry>
|
|
<entry>4.3-STABLE after PCI powerstate API
|
|
merge.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>440000</entry>
|
|
<entry>August 1, 2001</entry>
|
|
<entry>4.4-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>440001</entry>
|
|
<entry>October 23, 2001</entry>
|
|
<entry>4.4-STABLE after d_thread_t introduction.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>440002</entry>
|
|
<entry>November 4, 2001</entry>
|
|
<entry>4.4-STABLE after mount structure changes (affects
|
|
filesystem klds).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>440003</entry>
|
|
<entry>December 18, 2001</entry>
|
|
<entry>4.4-STABLE after the userland components of smbfs
|
|
were imported.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>450000</entry>
|
|
<entry>December 20, 2001</entry>
|
|
<entry>4.5-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>450001</entry>
|
|
<entry>February 24, 2002</entry>
|
|
<entry>4.5-STABLE after the usb structure element
|
|
rename.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>450004</entry>
|
|
<entry>April 16, 2002</entry>
|
|
<entry>4.5-STABLE after the
|
|
<literal>sendmail_enable</literal> &man.rc.conf.5;
|
|
variable was made to take the value
|
|
<literal>NONE</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>450005</entry>
|
|
<entry>April 27, 2002</entry>
|
|
<entry>4.5-STABLE after moving to XFree86 4 by default
|
|
for package builds.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>450006</entry>
|
|
<entry>May 1, 2002</entry>
|
|
<entry>4.5-STABLE after accept filtering was fixed so
|
|
that is no longer susceptible to an easy DoS.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>460000</entry>
|
|
<entry>June 21, 2002</entry>
|
|
<entry>4.6-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>460001</entry>
|
|
<entry>June 21, 2002</entry>
|
|
<entry>4.6-STABLE &man.sendfile.2; fixed to comply with
|
|
documentation, not to count any headers sent against
|
|
the amount of data to be sent from the file.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>460002</entry>
|
|
<entry>July 19, 2002</entry>
|
|
<entry>4.6.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>460100</entry>
|
|
<entry>June 26, 2002</entry>
|
|
<entry>4.6-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>460101</entry>
|
|
<entry>June 26, 2002</entry>
|
|
<entry>4.6-STABLE after MFC of `sed -i'.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>460102</entry>
|
|
<entry>September 1, 2002</entry>
|
|
<entry>4.6-STABLE after MFC of many new pkg_install
|
|
features from the HEAD.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>470000</entry>
|
|
<entry>October 8, 2002</entry>
|
|
<entry>4.7-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>470100</entry>
|
|
<entry>October 9, 2002</entry>
|
|
<entry>4.7-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>470101</entry>
|
|
<entry>November 10, 2002</entry>
|
|
<entry>Start generated __std{in,out,err}p references
|
|
rather than __sF. This changes std{in,out,err} from a
|
|
compile time expression to a runtime one.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>470102</entry>
|
|
<entry>January 23, 2003</entry>
|
|
<entry>4.7-STABLE after MFC of mbuf changes to replace
|
|
m_aux mbufs by m_tag's</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>470103</entry>
|
|
<entry>February 14, 2003</entry>
|
|
<entry>4.7-STABLE gets OpenSSL 0.9.7</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>480000</entry>
|
|
<entry>March 30, 2003</entry>
|
|
<entry>4.8-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>480100</entry>
|
|
<entry>April 5, 2003</entry>
|
|
<entry>4.8-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>480101</entry>
|
|
<entry>May 22, 2003</entry>
|
|
<entry>4.8-STABLE after &man.realpath.3; has been made
|
|
thread-safe</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>480102</entry>
|
|
<entry>August 10, 2003</entry>
|
|
<entry>4.8-STABLE 3ware API changes to twe.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>490000</entry>
|
|
<entry>October 27, 2003</entry>
|
|
<entry>4.9-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>490100</entry>
|
|
<entry>October 27, 2003</entry>
|
|
<entry>4.9-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>490101</entry>
|
|
<entry>January 8, 2004</entry>
|
|
<entry>4.9-STABLE after e_sid was added to struct
|
|
kinfo_eproc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>490102</entry>
|
|
<entry>February 4, 2004</entry>
|
|
<entry>4.9-STABLE after MFC of libmap functionality
|
|
for rtld.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>491000</entry>
|
|
<entry>May 25, 2004</entry>
|
|
<entry>4.10-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>491100</entry>
|
|
<entry>June 1, 2004</entry>
|
|
<entry>4.10-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>491101</entry>
|
|
<entry>August 11, 2004</entry>
|
|
<entry>4.10-STABLE after MFC of revision 20040629 of
|
|
the package tools</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>491102</entry>
|
|
<entry>November 16, 2004</entry>
|
|
<entry>4.10-STABLE after VM fix dealing with unwiring
|
|
of fictitious pages</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>492000</entry>
|
|
<entry>December 17, 2004</entry>
|
|
<entry>4.11-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>492100</entry>
|
|
<entry>December 17, 2004</entry>
|
|
<entry>4.11-STABLE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>492101</entry>
|
|
<entry>April 18, 2006</entry>
|
|
<entry>4.11-STABLE after adding libdata/ldconfig
|
|
directories to mtree files.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500000</entry>
|
|
<entry>March 13, 2000</entry>
|
|
<entry>5.0-CURRENT</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500001</entry>
|
|
<entry>April 18, 2000</entry>
|
|
<entry>5.0-CURRENT after adding addition ELF header
|
|
fields, and changing our ELF binary branding
|
|
method.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500002</entry>
|
|
<entry>May 2, 2000</entry>
|
|
<entry>5.0-CURRENT after kld metadata changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500003</entry>
|
|
<entry>May 18, 2000</entry>
|
|
<entry>5.0-CURRENT after buf/bio changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500004</entry>
|
|
<entry>May 26, 2000</entry>
|
|
<entry>5.0-CURRENT after binutils upgrade.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500005</entry>
|
|
<entry>June 3, 2000</entry>
|
|
<entry>5.0-CURRENT after merging libxpg4 code into
|
|
libc and after TASKQ interface introduction.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500006</entry>
|
|
<entry>June 10, 2000</entry>
|
|
<entry>5.0-CURRENT after the addition of AGP
|
|
interfaces.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500007</entry>
|
|
<entry>June 29, 2000</entry>
|
|
<entry>5.0-CURRENT after Perl upgrade to 5.6.0</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500008</entry>
|
|
<entry>July 7, 2000</entry>
|
|
<entry>5.0-CURRENT after the update of KAME code to
|
|
2000/07 sources.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500009</entry>
|
|
<entry>July 14, 2000</entry>
|
|
<entry>5.0-CURRENT after ether_ifattach() and
|
|
ether_ifdetach() changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500010</entry>
|
|
<entry>July 16, 2000</entry>
|
|
<entry>5.0-CURRENT after changing mtree defaults
|
|
back to original variant, adding -L to follow
|
|
symlinks.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500011</entry>
|
|
<entry>July 18, 2000</entry>
|
|
<entry>5.0-CURRENT after kqueue API changed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500012</entry>
|
|
<entry>September 2, 2000</entry>
|
|
<entry>5.0-CURRENT after &man.setproctitle.3; moved from
|
|
libutil to libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500013</entry>
|
|
<entry>September 10, 2000</entry>
|
|
<entry>5.0-CURRENT after the first SMPng commit.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500014</entry>
|
|
<entry>January 4, 2001</entry>
|
|
<entry>5.0-CURRENT after <sys/select.h> moved to
|
|
<sys/selinfo.h>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500015</entry>
|
|
<entry>January 10, 2001</entry>
|
|
<entry>5.0-CURRENT after combining libgcc.a and
|
|
libgcc_r.a, and associated GCC linkage
|
|
changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500016</entry>
|
|
<entry>January 24, 2001</entry>
|
|
<entry>5.0-CURRENT after change allowing libc and libc_r
|
|
to be linked together, deprecating -pthread
|
|
option.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500017</entry>
|
|
<entry>February 18, 2001</entry>
|
|
<entry>5.0-CURRENT after switch from struct ucred to
|
|
struct xucred to stabilize kernel-exported API for
|
|
mountd et al.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500018</entry>
|
|
<entry>February 24, 2001</entry>
|
|
<entry>5.0-CURRENT after addition of CPUTYPE make
|
|
variable for controlling CPU-specific
|
|
optimizations.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500019</entry>
|
|
<entry>June 9, 2001</entry>
|
|
<entry>5.0-CURRENT after moving machine/ioctl_fd.h to
|
|
sys/fdcio.h</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500020</entry>
|
|
<entry>June 15, 2001</entry>
|
|
<entry>5.0-CURRENT after locale names renaming.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500021</entry>
|
|
<entry>June 22, 2001</entry>
|
|
<entry>5.0-CURRENT after Bzip2 import.
|
|
Also signifies removal of S/Key.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500022</entry>
|
|
<entry>July 12, 2001</entry>
|
|
<entry>5.0-CURRENT after SSE support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500023</entry>
|
|
<entry>September 14, 2001</entry>
|
|
<entry>5.0-CURRENT after KSE Milestone 2.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500024</entry>
|
|
<entry>October 1, 2001</entry>
|
|
<entry>5.0-CURRENT after d_thread_t,
|
|
and moving UUCP to ports.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500025</entry>
|
|
<entry>October 4, 2001</entry>
|
|
<entry>5.0-CURRENT after ABI change for descriptor
|
|
and creds passing on 64 bit platforms.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500026</entry>
|
|
<entry>October 9, 2001</entry>
|
|
<entry>5.0-CURRENT after moving to XFree86 4 by default
|
|
for package builds, and after the new libc strnstr()
|
|
function was added.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500027</entry>
|
|
<entry>October 10, 2001</entry>
|
|
<entry>5.0-CURRENT after the new libc strcasestr()
|
|
function was added.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500028</entry>
|
|
<entry>December 14, 2001</entry>
|
|
<entry>5.0-CURRENT after the userland components of
|
|
smbfs were imported.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(not changed)</entry>
|
|
<entry></entry>
|
|
<entry>5.0-CURRENT after the new C99 specific-width
|
|
integer types were added.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500029</entry>
|
|
<entry>January 29, 2002</entry>
|
|
<entry>5.0-CURRENT after a change was made in the return
|
|
value of &man.sendfile.2;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500030</entry>
|
|
<entry>February 15, 2002</entry>
|
|
<entry>5.0-CURRENT after the introduction of the
|
|
type <literal>fflags_t</literal>, which is the
|
|
appropriate size for file flags.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500031</entry>
|
|
<entry>February 24, 2002</entry>
|
|
<entry>5.0-CURRENT after the usb structure element
|
|
rename.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500032</entry>
|
|
<entry>March 16, 2002</entry>
|
|
<entry>5.0-CURRENT after the introduction of
|
|
Perl 5.6.1.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500033</entry>
|
|
<entry>April 3, 2002</entry>
|
|
<entry>5.0-CURRENT after the
|
|
<literal>sendmail_enable</literal> &man.rc.conf.5;
|
|
variable was made to take the value
|
|
<literal>NONE</literal>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500034</entry>
|
|
<entry>April 30, 2002</entry>
|
|
<entry>5.0-CURRENT after mtx_init() grew a third
|
|
argument.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500035</entry>
|
|
<entry>May 13, 2002</entry>
|
|
<entry>5.0-CURRENT with Gcc 3.1.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500036</entry>
|
|
<entry>May 17, 2002</entry>
|
|
<entry>5.0-CURRENT without Perl in /usr/src</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500037</entry>
|
|
<entry>May 29, 2002</entry>
|
|
<entry>5.0-CURRENT after the addition of
|
|
&man.dlfunc.3;</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500038</entry>
|
|
<entry>July 24, 2002</entry>
|
|
<entry>5.0-CURRENT after the types of some struct
|
|
sockbuf members were changed and the structure was
|
|
reordered.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500039</entry>
|
|
<entry>September 1, 2002</entry>
|
|
<entry>5.0-CURRENT after GCC 3.2.1 import.
|
|
Also after headers stopped using
|
|
_BSD_FOO_T_ and started using _FOO_T_DECLARED.
|
|
This value can also be used as a conservative
|
|
estimate of the start of &man.bzip2.1; package
|
|
support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500040</entry>
|
|
<entry>September 20, 2002</entry>
|
|
<entry>5.0-CURRENT after various changes to disk
|
|
functions were made in the name of removing dependency
|
|
on disklabel structure internals.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500041</entry>
|
|
<entry>October 1, 2002</entry>
|
|
<entry>5.0-CURRENT after the addition of
|
|
&man.getopt.long.3; to libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500042</entry>
|
|
<entry>October 15, 2002</entry>
|
|
<entry>5.0-CURRENT after Binutils 2.13 upgrade, which
|
|
included new FreeBSD emulation, vec, and output
|
|
format.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500043</entry>
|
|
<entry>November 1, 2002</entry>
|
|
<entry>5.0-CURRENT after adding weak pthread_XXX stubs
|
|
to libc, obsoleting libXThrStub.so.
|
|
5.0-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500100</entry>
|
|
<entry>January 17, 2003</entry>
|
|
<entry>5.0-CURRENT after branching for
|
|
RELENG_5_0</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500101</entry>
|
|
<entry>February 19, 2003</entry>
|
|
<entry><sys/dkstat.h> is empty and should
|
|
not be included.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500102</entry>
|
|
<entry>February 25, 2003</entry>
|
|
<entry>5.0-CURRENT after the d_mmap_t interface
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500103</entry>
|
|
<entry>February 26, 2003</entry>
|
|
<entry>5.0-CURRENT after taskqueue_swi changed to run
|
|
without Giant, and taskqueue_swi_giant added to run
|
|
with Giant.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500104</entry>
|
|
<entry>February 27, 2003</entry>
|
|
<entry>cdevsw_add() and cdevsw_remove() no
|
|
longer exists.
|
|
Appearance of MAJOR_AUTO allocation facility.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500105</entry>
|
|
<entry>March 4, 2003</entry>
|
|
<entry>5.0-CURRENT after new cdevsw initialization
|
|
method.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500106</entry>
|
|
<entry>March 8, 2003</entry>
|
|
<entry>devstat_add_entry() has been replaced by
|
|
devstat_new_entry()</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500107</entry>
|
|
<entry>March 15, 2003</entry>
|
|
<entry>Devstat interface change; see sys/sys/param.h
|
|
1.149</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500108</entry>
|
|
<entry>March 15, 2003</entry>
|
|
<entry>Token-Ring interface changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500109</entry>
|
|
<entry>March 25, 2003</entry>
|
|
<entry>Addition of vm_paddr_t.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500110</entry>
|
|
<entry>March 28, 2003</entry>
|
|
<entry>5.0-CURRENT after &man.realpath.3; has been made
|
|
thread-safe</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500111</entry>
|
|
<entry>April 9, 2003</entry>
|
|
<entry>5.0-CURRENT after &man.usbhid.3; has been synced
|
|
with NetBSD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500112</entry>
|
|
<entry>April 17, 2003</entry>
|
|
<entry>5.0-CURRENT after new NSS implementation
|
|
and addition of POSIX.1 getpw*_r, getgr*_r
|
|
functions</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>500113</entry>
|
|
<entry>May 2, 2003</entry>
|
|
<entry>5.0-CURRENT after removal of the old rc
|
|
system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501000</entry>
|
|
<entry>June 4, 2003</entry>
|
|
<entry>5.1-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501100</entry>
|
|
<entry>June 2, 2003</entry>
|
|
<entry>5.1-CURRENT after branching for
|
|
RELENG_5_1.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501101</entry>
|
|
<entry>June 29, 2003</entry>
|
|
<entry>5.1-CURRENT after correcting the semantics of
|
|
sigtimedwait(2) and sigwaitinfo(2).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501102</entry>
|
|
<entry>July 3, 2003</entry>
|
|
<entry>5.1-CURRENT after adding the lockfunc and
|
|
lockfuncarg fields to
|
|
&man.bus.dma.tag.create.9;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501103</entry>
|
|
<entry>July 31, 2003</entry>
|
|
<entry>5.1-CURRENT after GCC 3.3.1-pre 20030711 snapshot
|
|
integration.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501104</entry>
|
|
<entry>August 5, 2003</entry>
|
|
<entry>5.1-CURRENT 3ware API changes to twe.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501105</entry>
|
|
<entry>August 17, 2003</entry>
|
|
<entry>5.1-CURRENT dynamically-linked /bin and /sbin
|
|
support and movement of libraries to /lib.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501106</entry>
|
|
<entry>September 8, 2003</entry>
|
|
<entry>5.1-CURRENT after adding kernel support for
|
|
Coda 6.x.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501107</entry>
|
|
<entry>September 17, 2003</entry>
|
|
<entry>5.1-CURRENT after 16550 UART constants moved from
|
|
<filename><dev/sio/sioreg.h></filename> to
|
|
<filename><dev/ic/ns16550.h></filename>.
|
|
Also when libmap functionality was unconditionally
|
|
supported by rtld.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501108</entry>
|
|
<entry>September 23, 2003</entry>
|
|
<entry>5.1-CURRENT after PFIL_HOOKS API update</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501109</entry>
|
|
<entry>September 27, 2003</entry>
|
|
<entry>5.1-CURRENT after adding kiconv(3)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501110</entry>
|
|
<entry>September 28, 2003</entry>
|
|
<entry>5.1-CURRENT after changing default operations
|
|
for open and close in cdevsw</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501111</entry>
|
|
<entry>October 16, 2003</entry>
|
|
<entry>5.1-CURRENT after changed layout of
|
|
cdevsw</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501112</entry>
|
|
<entry>October 16, 2003</entry>
|
|
<entry> 5.1-CURRENT after adding kobj multiple
|
|
inheritance</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501113</entry>
|
|
<entry>October 31, 2003</entry>
|
|
<entry> 5.1-CURRENT after the if_xname change in
|
|
struct ifnet</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>501114</entry>
|
|
<entry>November 16, 2003</entry>
|
|
<entry> 5.1-CURRENT after changing /bin and /sbin to
|
|
be dynamically linked</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502000</entry>
|
|
<entry>December 7, 2003</entry>
|
|
<entry>5.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502010</entry>
|
|
<entry>February 23, 2004</entry>
|
|
<entry>5.2.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502100</entry>
|
|
<entry>December 7, 2003</entry>
|
|
<entry>5.2-CURRENT after branching for
|
|
RELENG_5_2</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502101</entry>
|
|
<entry>December 19, 2003</entry>
|
|
<entry>5.2-CURRENT after __cxa_atexit/__cxa_finalize
|
|
functions were added to libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502102</entry>
|
|
<entry>January 30, 2004</entry>
|
|
<entry>5.2-CURRENT after change of default thread
|
|
library from libc_r to libpthread.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502103</entry>
|
|
<entry>February 21, 2004</entry>
|
|
<entry>5.2-CURRENT after device driver API
|
|
megapatch.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502104</entry>
|
|
<entry>February 25, 2004</entry>
|
|
<entry>5.2-CURRENT after getopt_long_only()
|
|
addition.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502105</entry>
|
|
<entry>March 5, 2004</entry>
|
|
<entry>5.2-CURRENT after NULL is made into ((void *)0)
|
|
for C, creating more warnings.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502106</entry>
|
|
<entry>March 8, 2004</entry>
|
|
<entry>5.2-CURRENT after pf is linked to the build and
|
|
install.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502107</entry>
|
|
<entry>March 10, 2004</entry>
|
|
<entry>5.2-CURRENT after time_t is changed to a
|
|
64-bit value on sparc64.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502108</entry>
|
|
<entry>March 12, 2004</entry>
|
|
<entry>5.2-CURRENT after Intel C/C++ compiler support in
|
|
some headers and execve(2) changes to be more strictly
|
|
conforming to POSIX.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502109</entry>
|
|
<entry>March 22, 2004</entry>
|
|
<entry>5.2-CURRENT after the introduction of the
|
|
bus_alloc_resource_any API</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502110</entry>
|
|
<entry>March 27, 2004</entry>
|
|
<entry>5.2-CURRENT after the addition of UTF-8
|
|
locales</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502111</entry>
|
|
<entry>April 11, 2004</entry>
|
|
<entry>5.2-CURRENT after the removal of the getvfsent(3)
|
|
API</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502112</entry>
|
|
<entry>April 13, 2004</entry>
|
|
<entry>5.2-CURRENT after the addition of the .warning
|
|
directive for make.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502113</entry>
|
|
<entry>June 4, 2004</entry>
|
|
<entry>5.2-CURRENT after ttyioctl() was made mandatory
|
|
for serial drivers.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502114</entry>
|
|
<entry>June 13, 2004</entry>
|
|
<entry>5.2-CURRENT after import of the ALTQ
|
|
framework.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502115</entry>
|
|
<entry>June 14, 2004</entry>
|
|
<entry>5.2-CURRENT after changing sema_timedwait(9) to
|
|
return 0 on success and a non-zero error code on
|
|
failure.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502116</entry>
|
|
<entry>June 16, 2004</entry>
|
|
<entry>5.2-CURRENT after changing kernel dev_t to be
|
|
pointer to struct cdev *.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502117</entry>
|
|
<entry>June 17, 2004</entry>
|
|
<entry>5.2-CURRENT after changing kernel udev_t to
|
|
dev_t.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502118</entry>
|
|
<entry>June 17, 2004</entry>
|
|
<entry>5.2-CURRENT after adding support for
|
|
CLOCK_VIRTUAL and CLOCK_PROF to clock_gettime(2) and
|
|
clock_getres(2).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502119</entry>
|
|
<entry>June 22, 2004</entry>
|
|
<entry>5.2-CURRENT after changing network interface
|
|
cloning overhaul.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502120</entry>
|
|
<entry>July 2, 2004</entry>
|
|
<entry>5.2-CURRENT after the update of the package tools
|
|
to revision 20040629.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502121</entry>
|
|
<entry>July 9, 2004</entry>
|
|
<entry>5.2-CURRENT after marking Bluetooth code as
|
|
non-i386 specific.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502122</entry>
|
|
<entry>July 11, 2004</entry>
|
|
<entry>5.2-CURRENT after the introduction of the KDB
|
|
debugger framework, the conversion of DDB into a
|
|
backend and the introduction of the GDB
|
|
backend.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502123</entry>
|
|
<entry>July 12, 2004</entry>
|
|
<entry>5.2-CURRENT after change to make VFS_ROOT take a
|
|
struct thread argument as does vflush. Struct
|
|
kinfo_proc now has a user data pointer. The switch of
|
|
the default X implementation to
|
|
<literal>xorg</literal> was also made at this
|
|
time.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502124</entry>
|
|
<entry>July 24, 2004</entry>
|
|
<entry>5.2-CURRENT after the change to separate the way
|
|
ports rc.d and legacy scripts are started.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502125</entry>
|
|
<entry>July 28, 2004</entry>
|
|
<entry>5.2-CURRENT after the backout of the previous
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502126</entry>
|
|
<entry>July 31, 2004</entry>
|
|
<entry>5.2-CURRENT after the removal of
|
|
kmem_alloc_pageable() and the import of gcc
|
|
3.4.2.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502127</entry>
|
|
<entry>August 2, 2004</entry>
|
|
<entry>5.2-CURRENT after changing the UMA kernel
|
|
API to allow ctors/inits to fail.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>502128</entry>
|
|
<entry>August 8, 2004</entry>
|
|
<entry>5.2-CURRENT after the change of the
|
|
vfs_mount signature as well as global replacement of
|
|
PRISON_ROOT with SUSER_ALLOWJAIL for the suser(9)
|
|
API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503000</entry>
|
|
<entry>August 23, 2004</entry>
|
|
<entry>5.3-BETA/RC before the pfil API change</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503001</entry>
|
|
<entry>September 22, 2004</entry>
|
|
<entry>5.3-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503100</entry>
|
|
<entry>October 16, 2004</entry>
|
|
<entry>5.3-STABLE after branching for RELENG_5_3</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503101</entry>
|
|
<entry>December 3, 2004</entry>
|
|
<entry>5.3-STABLE after addition of glibc style
|
|
&man.strftime.3; padding options.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503102</entry>
|
|
<entry>February 13, 2005</entry>
|
|
<entry>5.3-STABLE after OpenBSD's nc(1) import
|
|
MFC.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503103</entry>
|
|
<entry>February 27, 2005</entry>
|
|
<entry>5.4-PRERELEASE after the MFC of the fixes in
|
|
<filename><src/include/stdbool.h></filename> and
|
|
<filename><src/sys/i386/include/_types.h></filename>
|
|
for using the GCC-compatibility of the Intel C/C++
|
|
compiler.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503104</entry>
|
|
<entry>February 28, 2005</entry>
|
|
<entry>5.4-PRERELEASE after the MFC of the change of
|
|
ifi_epoch from wall clock time to uptime.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>503105</entry>
|
|
<entry>March 2, 2005</entry>
|
|
<entry>5.4-PRERELEASE after the MFC of the fix of
|
|
EOVERFLOW check in vswprintf(3).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>504000</entry>
|
|
<entry>April 3, 2005</entry>
|
|
<entry>5.4-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>504100</entry>
|
|
<entry>April 3, 2005</entry>
|
|
<entry>5.4-STABLE after branching for RELENG_5_4</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>504101</entry>
|
|
<entry>May 11, 2005</entry>
|
|
<entry>5.4-STABLE after increasing the default
|
|
thread stacksizes</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>504102</entry>
|
|
<entry>June 24, 2005</entry>
|
|
<entry>5.4-STABLE after the addition of sha256</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>504103</entry>
|
|
<entry>October 3, 2005</entry>
|
|
<entry>5.4-STABLE after the MFC of if_bridge</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>504104</entry>
|
|
<entry>November 13, 2005</entry>
|
|
<entry>5.4-STABLE after the MFC of bsdiff and
|
|
portsnap</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>504105</entry>
|
|
<entry>January 17, 2006</entry>
|
|
<entry>5.4-STABLE after MFC of ldconfig_local_dirs
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>505000</entry>
|
|
<entry>May 12, 2006</entry>
|
|
<entry>5.5-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>505100</entry>
|
|
<entry>May 12, 2006</entry>
|
|
<entry>5.5-STABLE after branching for RELENG_5_5</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600000</entry>
|
|
<entry>August 18, 2004</entry>
|
|
<entry>6.0-CURRENT</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600001</entry>
|
|
<entry>August 27, 2004</entry>
|
|
<entry>6.0-CURRENT after permanently enabling PFIL_HOOKS
|
|
in the kernel.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600002</entry>
|
|
<entry>August 30, 2004</entry>
|
|
<entry>6.0-CURRENT after initial addition of
|
|
ifi_epoch to struct if_data. Backed out after a
|
|
few days. Do not use this value.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600003</entry>
|
|
<entry>September 8, 2004</entry>
|
|
<entry>6.0-CURRENT after the re-addition of the
|
|
ifi_epoch member of struct if_data.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600004</entry>
|
|
<entry>September 29, 2004</entry>
|
|
<entry>6.0-CURRENT after addition of the struct inpcb
|
|
argument to the pfil API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600005</entry>
|
|
<entry>October 5, 2004</entry>
|
|
<entry>6.0-CURRENT after addition of the "-d
|
|
DESTDIR" argument to newsyslog.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600006</entry>
|
|
<entry>November 4, 2004</entry>
|
|
<entry>6.0-CURRENT after addition of glibc style
|
|
&man.strftime.3; padding options.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600007</entry>
|
|
<entry>December 12, 2004</entry>
|
|
<entry>6.0-CURRENT after addition of 802.11 framework
|
|
updates.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600008</entry>
|
|
<entry>January 25, 2005</entry>
|
|
<entry>6.0-CURRENT after changes to VOP_*VOBJECT()
|
|
functions and introduction of MNTK_MPSAFE flag for
|
|
Giantfree filesystems.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600009</entry>
|
|
<entry>February 4, 2005</entry>
|
|
<entry>6.0-CURRENT after addition of the cpufreq
|
|
framework and drivers.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600010</entry>
|
|
<entry>February 6, 2005</entry>
|
|
<entry>6.0-CURRENT after importing OpenBSD's
|
|
nc(1).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600011</entry>
|
|
<entry>February 12, 2005</entry>
|
|
<entry>6.0-CURRENT after removing semblance of SVID2
|
|
<literal>matherr()</literal> support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600012</entry>
|
|
<entry>February 15, 2005</entry>
|
|
<entry>6.0-CURRENT after increase of default thread
|
|
stacks' size.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600013</entry>
|
|
<entry>February 19, 2005</entry>
|
|
<entry>6.0-CURRENT after fixes in
|
|
<filename><src/include/stdbool.h></filename> and
|
|
<filename><src/sys/i386/include/_types.h></filename>
|
|
for using the GCC-compatibility of the Intel C/C++
|
|
compiler.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600014</entry>
|
|
<entry>February 21, 2005</entry>
|
|
<entry>6.0-CURRENT after EOVERFLOW checks in
|
|
vswprintf(3) fixed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600015</entry>
|
|
<entry>February 25, 2005</entry>
|
|
<entry>6.0-CURRENT after changing the struct if_data
|
|
member, ifi_epoch, from wall clock time to
|
|
uptime.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600016</entry>
|
|
<entry>February 26, 2005</entry>
|
|
<entry>6.0-CURRENT after LC_CTYPE disk format
|
|
changed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600017</entry>
|
|
<entry>February 27, 2005</entry>
|
|
<entry>6.0-CURRENT after NLS catalogs disk format
|
|
changed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600018</entry>
|
|
<entry>February 27, 2005</entry>
|
|
<entry>6.0-CURRENT after LC_COLLATE disk format
|
|
changed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600019</entry>
|
|
<entry>February 28, 2005</entry>
|
|
<entry>Installation of acpica includes into
|
|
/usr/include.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600020</entry>
|
|
<entry>March 9, 2005</entry>
|
|
<entry>Addition of MSG_NOSIGNAL flag to send(2)
|
|
API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600021</entry>
|
|
<entry>March 17, 2005</entry>
|
|
<entry>Addition of fields to cdevsw</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600022</entry>
|
|
<entry>March 21, 2005</entry>
|
|
<entry>Removed gtar from base system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600023</entry>
|
|
<entry>April 13, 2005</entry>
|
|
<entry>LOCAL_CREDS, LOCAL_CONNWAIT socket options added
|
|
to unix(4).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600024</entry>
|
|
<entry>April 19, 2005</entry>
|
|
<entry>&man.hwpmc.4; and related tools added to
|
|
6.0-CURRENT.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600025</entry>
|
|
<entry>April 26, 2005</entry>
|
|
<entry>struct icmphdr added to 6.0-CURRENT.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600026</entry>
|
|
<entry>May 3, 2005</entry>
|
|
<entry>pf updated to 3.7.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600027</entry>
|
|
<entry>May 6, 2005</entry>
|
|
<entry>Kernel libalias and ng_nat introduced.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600028</entry>
|
|
<entry>May 13, 2005</entry>
|
|
<entry>POSIX ttyname_r(3) made available through
|
|
unistd.h and libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600029</entry>
|
|
<entry>May 29, 2005</entry>
|
|
<entry>6.0-CURRENT after libpcap updated to v0.9.1 alpha
|
|
096.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600030</entry>
|
|
<entry>June 5, 2005</entry>
|
|
<entry>6.0-CURRENT after importing NetBSD's
|
|
if_bridge(4).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600031</entry>
|
|
<entry>June 10, 2005</entry>
|
|
<entry>6.0-CURRENT after struct ifnet was broken out
|
|
of the driver softcs.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600032</entry>
|
|
<entry>July 11, 2005</entry>
|
|
<entry>6.0-CURRENT after the import of libpcap
|
|
v0.9.1.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600033</entry>
|
|
<entry>July 25, 2005</entry>
|
|
<entry>6.0-STABLE after bump of all shared library
|
|
versions that had not been changed since
|
|
RELENG_5.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600034</entry>
|
|
<entry>August 13, 2005</entry>
|
|
<entry>6.0-STABLE after credential argument is added to
|
|
dev_clone event handler. 6.0-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600100</entry>
|
|
<entry>November 1, 2005</entry>
|
|
<entry>6.0-STABLE after 6.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600101</entry>
|
|
<entry>December 21, 2005</entry>
|
|
<entry>6.0-STABLE after incorporating scripts from the
|
|
local_startup directories into the base
|
|
&man.rcorder.8;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600102</entry>
|
|
<entry>December 30, 2005</entry>
|
|
<entry>6.0-STABLE after updating the ELF types and
|
|
constants.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600103</entry>
|
|
<entry>January 15, 2006</entry>
|
|
<entry>6.0-STABLE after MFC of pidfile(3) API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600104</entry>
|
|
<entry>January 17, 2006</entry>
|
|
<entry>6.0-STABLE after MFC of ldconfig_local_dirs
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>600105</entry>
|
|
<entry>February 26, 2006</entry>
|
|
<entry>6.0-STABLE after NLS catalog support of
|
|
csh(1).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>601000</entry>
|
|
<entry>May 6, 2006</entry>
|
|
<entry>6.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>601100</entry>
|
|
<entry>May 6, 2006</entry>
|
|
<entry>6.1-STABLE after 6.1-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>601101</entry>
|
|
<entry>June 22, 2006</entry>
|
|
<entry>6.1-STABLE after the import of csup.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>601102</entry>
|
|
<entry>July 11, 2006</entry>
|
|
<entry>6.1-STABLE after the iwi(4) update.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>601103</entry>
|
|
<entry>July 17, 2006</entry>
|
|
<entry>6.1-STABLE after the resolver update to
|
|
BIND9, and exposure of reentrant version of
|
|
netdb functions.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>601104</entry>
|
|
<entry>August 8, 2006</entry>
|
|
<entry>6.1-STABLE after DSO (dynamic shared
|
|
objects) support has been enabled in
|
|
OpenSSL.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>601105</entry>
|
|
<entry>September 2, 2006</entry>
|
|
<entry>6.1-STABLE after 802.11 fixups changed the
|
|
api for the IEEE80211_IOC_STA_INFO ioctl.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602000</entry>
|
|
<entry>November 15, 2006</entry>
|
|
<entry>6.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602100</entry>
|
|
<entry>September 15, 2006</entry>
|
|
<entry>6.2-STABLE after 6.2-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602101</entry>
|
|
<entry>December 12, 2006</entry>
|
|
<entry>6.2-STABLE after the addition of Wi-Spy
|
|
quirk.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602102</entry>
|
|
<entry>December 28, 2006</entry>
|
|
<entry>6.2-STABLE after pci_find_extcap()
|
|
addition.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602103</entry>
|
|
<entry>January 16, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of dlsym change to look for
|
|
a requested symbol both in specified dso and its
|
|
implicit dependencies.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602104</entry>
|
|
<entry>January 28, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of ng_deflate(4) and
|
|
ng_pred1(4) netgraph nodes and new compression and
|
|
encryption modes for ng_ppp(4) node.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602105</entry>
|
|
<entry>February 20, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of BSD licensed version of
|
|
&man.gzip.1; ported from NetBSD.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602106</entry>
|
|
<entry>March 31, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of PCI MSI and MSI-X
|
|
support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602107</entry>
|
|
<entry>April 6, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of ncurses 5.6 and wide
|
|
character support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602108</entry>
|
|
<entry>April 11, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of CAM 'SG' peripheral
|
|
device, which implements a subset of Linux SCSI SG
|
|
passthrough device API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602109</entry>
|
|
<entry>April 17, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of readline 5.2 patchset
|
|
002.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602110</entry>
|
|
<entry>May 2, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of pmap_invalidate_cache(),
|
|
pmap_change_attr(), pmap_mapbios(),
|
|
pmap_mapdev_attr(), and pmap_unmapbios() for amd64 and
|
|
i386.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602111</entry>
|
|
<entry>June 11, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of BOP_BDFLUSH and caused
|
|
breakage of the filesystem modules KBI.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602112</entry>
|
|
<entry>September 21, 2007</entry>
|
|
<entry>6.2-STABLE after libutil(3) MFC's.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602113</entry>
|
|
<entry>October 25, 2007</entry>
|
|
<entry>6.2-STABLE after MFC of wide and single byte
|
|
ctype separation. Newly compiled binary that
|
|
references to ctype.h may require a new symbol,
|
|
__mb_sb_limit, which is not available on older
|
|
systems.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602114</entry>
|
|
<entry>October 30, 2007</entry>
|
|
<entry>6.2-STABLE after ctype ABI forward compatibility
|
|
restored.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>602115</entry>
|
|
<entry>November 21, 2007</entry>
|
|
<entry>6.2-STABLE after back out of wide and single byte
|
|
ctype separation.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>603000</entry>
|
|
<entry>November 25, 2007</entry>
|
|
<entry>6.3-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>603100</entry>
|
|
<entry>November 25, 2007</entry>
|
|
<entry>6.3-STABLE after 6.3-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>603101</entry>
|
|
<entry>December 7, 2007</entry>
|
|
<entry>6.3-STABLE after fixing
|
|
multibyte type support in bit macro.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>603102</entry>
|
|
<entry>April 24, 2008</entry>
|
|
<entry>6.3-STABLE after adding l_sysid to struct
|
|
flock.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>603103</entry>
|
|
<entry>May 27, 2008</entry>
|
|
<entry>6.3-STABLE after MFC of the
|
|
<function>memrchr</function> function.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>603104</entry>
|
|
<entry>June 15, 2008</entry>
|
|
<entry>6.3-STABLE after MFC of support for
|
|
<literal>:u</literal> variable modifier in
|
|
make(1).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>604000</entry>
|
|
<entry>October 4, 2008</entry>
|
|
<entry>6.4-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>604100</entry>
|
|
<entry>October 4, 2008</entry>
|
|
<entry>6.4-STABLE after 6.4-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700000</entry>
|
|
<entry>July 11, 2005</entry>
|
|
<entry>7.0-CURRENT.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700001</entry>
|
|
<entry>July 23, 2005</entry>
|
|
<entry>7.0-CURRENT after bump of all shared library
|
|
versions that had not been changed since
|
|
RELENG_5.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700002</entry>
|
|
<entry>August 13, 2005</entry>
|
|
<entry>7.0-CURRENT after credential argument is added to
|
|
dev_clone event handler.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700003</entry>
|
|
<entry>August 25, 2005</entry>
|
|
<entry>7.0-CURRENT after memmem(3) is added to
|
|
libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700004</entry>
|
|
<entry>October 30, 2005</entry>
|
|
<entry>7.0-CURRENT after solisten(9) kernel arguments
|
|
are modified to accept a backlog parameter.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700005</entry>
|
|
<entry>November 11, 2005</entry>
|
|
<entry>7.0-CURRENT after IFP2ENADDR() was changed to
|
|
return a pointer to IF_LLADDR().</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700006</entry>
|
|
<entry>November 11, 2005</entry>
|
|
<entry>7.0-CURRENT after addition of
|
|
<literal>if_addr</literal> member to <literal>struct
|
|
ifnet</literal> and IFP2ENADDR() removal.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700007</entry>
|
|
<entry>December 2, 2005</entry>
|
|
<entry>7.0-CURRENT after incorporating scripts from the
|
|
local_startup directories into the base
|
|
&man.rcorder.8;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700008</entry>
|
|
<entry>December 5, 2005</entry>
|
|
<entry>7.0-CURRENT after removal of MNT_NODEV mount
|
|
option.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700009</entry>
|
|
<entry>December 19, 2005</entry>
|
|
<entry>7.0-CURRENT after ELF-64 type changes and symbol
|
|
versioning.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700010</entry>
|
|
<entry>December 20, 2005</entry>
|
|
<entry>7.0-CURRENT after addition of hostb and vgapci
|
|
drivers, addition of pci_find_extcap(), and changing
|
|
the AGP drivers to no longer map the aperture.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700011</entry>
|
|
<entry>December 31, 2005</entry>
|
|
<entry>7.0-CURRENT after tv_sec was made time_t on
|
|
all platforms but Alpha.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700012</entry>
|
|
<entry>January 8, 2006</entry>
|
|
<entry>7.0-CURRENT after ldconfig_local_dirs
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700013</entry>
|
|
<entry>January 12, 2006</entry>
|
|
<entry>7.0-CURRENT after changes to
|
|
<filename>/etc/rc.d/abi</filename> to support
|
|
<filename>/compat/linux/etc/ld.so.cache</filename>
|
|
being a symlink in a readonly filesystem.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700014</entry>
|
|
<entry>January 26, 2006</entry>
|
|
<entry>7.0-CURRENT after pts import.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700015</entry>
|
|
<entry>March 26, 2006</entry>
|
|
<entry>7.0-CURRENT after the introduction of version 2
|
|
of &man.hwpmc.4;'s ABI.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700016</entry>
|
|
<entry>April 22, 2006</entry>
|
|
<entry>7.0-CURRENT after addition of &man.fcloseall.3;
|
|
to libc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700017</entry>
|
|
<entry>May 13, 2006</entry>
|
|
<entry>7.0-CURRENT after removal of ip6fw.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700018</entry>
|
|
<entry>July 15, 2006</entry>
|
|
<entry>7.0-CURRENT after import of snd_emu10kx.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700019</entry>
|
|
<entry>July 29, 2006</entry>
|
|
<entry>7.0-CURRENT after import of OpenSSL
|
|
0.9.8b.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700020</entry>
|
|
<entry>September 3, 2006</entry>
|
|
<entry>7.0-CURRENT after addition of bus_dma_get_tag
|
|
function</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700021</entry>
|
|
<entry>September 4, 2006</entry>
|
|
<entry>7.0-CURRENT after libpcap 0.9.4 and tcpdump 3.9.4
|
|
import.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700022</entry>
|
|
<entry>September 9, 2006</entry>
|
|
<entry>7.0-CURRENT after dlsym change to look for a
|
|
requested symbol both in specified dso and its
|
|
implicit dependencies.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700023</entry>
|
|
<entry>September 23, 2006</entry>
|
|
<entry>7.0-CURRENT after adding new sound IOCTLs for the
|
|
OSSv4 mixer API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700024</entry>
|
|
<entry>September 28, 2006</entry>
|
|
<entry>7.0-CURRENT after import of OpenSSL
|
|
0.9.8d.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700025</entry>
|
|
<entry>November 11, 2006</entry>
|
|
<entry>7.0-CURRENT after the addition of libelf.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700026</entry>
|
|
<entry>November 26, 2006</entry>
|
|
<entry>7.0-CURRENT after major changes on sound
|
|
sysctls.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700027</entry>
|
|
<entry>November 30, 2006</entry>
|
|
<entry>7.0-CURRENT after the addition of Wi-Spy
|
|
quirk.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700028</entry>
|
|
<entry>December 15, 2006</entry>
|
|
<entry>7.0-CURRENT after the addition of sctp calls to
|
|
libc</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700029</entry>
|
|
<entry>January 26, 2007</entry>
|
|
<entry>7.0-CURRENT after the GNU &man.gzip.1;
|
|
implementation was replaced with a BSD licensed
|
|
version ported from NetBSD.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700030</entry>
|
|
<entry>February 7, 2007</entry>
|
|
<entry>7.0-CURRENT after the removal of IPIP tunnel
|
|
encapsulation (VIFF_TUNNEL) from the IPv4 multicast
|
|
forwarding code.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700031</entry>
|
|
<entry>February 23, 2007</entry>
|
|
<entry>7.0-CURRENT after the modification of
|
|
bus_setup_intr() (newbus).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700032</entry>
|
|
<entry>March 2, 2007</entry>
|
|
<entry>7.0-CURRENT after the inclusion of ipw(4) and
|
|
iwi(4) firmware.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700033</entry>
|
|
<entry>March 9, 2007</entry>
|
|
<entry>7.0-CURRENT after the inclusion of ncurses wide
|
|
character support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700034</entry>
|
|
<entry>March 19, 2007</entry>
|
|
<entry>7.0-CURRENT after changes to how insmntque(),
|
|
getnewvnode(), and vfs_hash_insert() work.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700035</entry>
|
|
<entry>March 26, 2007</entry>
|
|
<entry>7.0-CURRENT after addition of a notify mechanism
|
|
for CPU frequency changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700036</entry>
|
|
<entry>April 6, 2007</entry>
|
|
<entry>7.0-CURRENT after import of the ZFS
|
|
filesystem.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700037</entry>
|
|
<entry>April 8, 2007</entry>
|
|
<entry>7.0-CURRENT after addition of CAM 'SG' peripheral
|
|
device, which implements a subset of Linux SCSI SG
|
|
passthrough device API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700038</entry>
|
|
<entry>April 30, 2007</entry>
|
|
<entry>7.0-CURRENT after changing &man.getenv.3;,
|
|
&man.putenv.3;, &man.setenv.3; and &man.unsetenv.3; to
|
|
be POSIX conformant.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700039</entry>
|
|
<entry>May 1, 2007</entry>
|
|
<entry>7.0-CURRENT after the changes in 700038 were
|
|
backed out.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700040</entry>
|
|
<entry>May 10, 2007</entry>
|
|
<entry>7.0-CURRENT after the addition of &man.flopen.3;
|
|
to libutil.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700041</entry>
|
|
<entry>May 13, 2007</entry>
|
|
<entry>7.0-CURRENT after enabling symbol versioning, and
|
|
changing the default thread library to libthr.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700042</entry>
|
|
<entry>May 19, 2007</entry>
|
|
<entry>7.0-CURRENT after the import of gcc
|
|
4.2.0.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700043</entry>
|
|
<entry>May 21, 2007</entry>
|
|
<entry>7.0-CURRENT after bump of all shared library
|
|
versions that had not been changed since
|
|
RELENG_6.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700044</entry>
|
|
<entry>June 7, 2007</entry>
|
|
<entry>7.0-CURRENT after changing the argument for
|
|
vn_open()/VOP_OPEN() from file descriptor index to the
|
|
struct file *.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700045</entry>
|
|
<entry>June 10, 2007</entry>
|
|
<entry>7.0-CURRENT after changing &man.pam.nologin.8; to
|
|
provide an account management function instead of an
|
|
authentication function to the PAM framework.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700046</entry>
|
|
<entry>June 11, 2007</entry>
|
|
<entry>7.0-CURRENT after updated 802.11 wireless
|
|
support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700047</entry>
|
|
<entry>June 11, 2007</entry>
|
|
<entry>7.0-CURRENT after adding TCP LRO interface
|
|
capabilities.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700048</entry>
|
|
<entry>June 12, 2007</entry>
|
|
<entry>7.0-CURRENT after
|
|
RFC 3678 API support added to the IPv4 stack.
|
|
Legacy RFC 1724 behavior of the IP_MULTICAST_IF
|
|
ioctl has now been removed; 0.0.0.0/8 may no longer
|
|
be used to specify an interface index.
|
|
struct ipmreqn should be used instead.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700049</entry>
|
|
<entry>July 3, 2007</entry>
|
|
<entry>7.0-CURRENT after importing pf from OpenBSD
|
|
4.1</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(not changed)</entry>
|
|
<entry></entry>
|
|
<entry>7.0-CURRENT after adding IPv6 support for
|
|
FAST_IPSEC, deleting KAME IPSEC, and renaming
|
|
FAST_IPSEC to IPSEC.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700050</entry>
|
|
<entry>July 4, 2007</entry>
|
|
<entry>7.0-CURRENT after converting setenv/putenv/etc.
|
|
calls from traditional BSD to POSIX.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700051</entry>
|
|
<entry>July 4, 2007</entry>
|
|
<entry>7.0-CURRENT after adding new mmap/lseek/etc
|
|
syscalls.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700052</entry>
|
|
<entry>July 6, 2007</entry>
|
|
<entry>7.0-CURRENT after moving I4B headers to
|
|
include/i4b.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700053</entry>
|
|
<entry>September 30, 2007</entry>
|
|
<entry>7.0-CURRENT after the addition of support for
|
|
PCI domains</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700054</entry>
|
|
<entry>October 25, 2007</entry>
|
|
<entry>7.0-CURRENT after MFC of wide and single byte
|
|
ctype separation.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700055</entry>
|
|
<entry>October 28, 2007</entry>
|
|
<entry>7.0-RELEASE, and 7.0-CURRENT after ABI backwards
|
|
compatibility to the FreeBSD 4/5/6 versions of the
|
|
PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs was
|
|
MFCed, which required the ABI of the PCIOCGETCONF
|
|
IOCTL to be broken again</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700100</entry>
|
|
<entry>December 22, 2007</entry>
|
|
<entry>7.0-STABLE after 7.0-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700101</entry>
|
|
<entry>February 8, 2008</entry>
|
|
<entry>7.0-STABLE after the MFC of m_collapse().</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700102</entry>
|
|
<entry>March 30, 2008</entry>
|
|
<entry>7.0-STABLE after the MFC of
|
|
kdb_enter_why().</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700103</entry>
|
|
<entry>April 10, 2008</entry>
|
|
<entry>7.0-STABLE after adding l_sysid to struct
|
|
flock.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700104</entry>
|
|
<entry>April 11, 2008</entry>
|
|
<entry>7.0-STABLE after the MFC of procstat(1).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700105</entry>
|
|
<entry>April 11, 2008</entry>
|
|
<entry>7.0-STABLE after the MFC of umtx
|
|
features.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700106</entry>
|
|
<entry>April 15, 2008</entry>
|
|
<entry>7.0-STABLE after the MFC of &man.write.2; support
|
|
to &man.psm.4;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700107</entry>
|
|
<entry>April 20, 2008</entry>
|
|
<entry>7.0-STABLE after the MFC of F_DUP2FD command
|
|
to &man.fcntl.2;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700108</entry>
|
|
<entry>May 5, 2008</entry>
|
|
<entry>7.0-STABLE after some &man.lockmgr.9; changes,
|
|
which makes it necessary to include
|
|
<filename>sys/lock.h</filename> in order to use
|
|
&man.lockmgr.9;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700109</entry>
|
|
<entry>May 27, 2008</entry>
|
|
<entry>7.0-STABLE after MFC of the
|
|
<function>memrchr</function> function.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700110</entry>
|
|
<entry>August 5, 2008</entry>
|
|
<entry>7.0-STABLE after MFC of kernel NFS lockd
|
|
client.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700111</entry>
|
|
<entry>August 20, 2008</entry>
|
|
<entry>7.0-STABLE after addition of physically
|
|
contiguous jumbo frame support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>700112</entry>
|
|
<entry>August 27, 2008</entry>
|
|
<entry>7.0-STABLE after MFC of kernel DTrace
|
|
support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701000</entry>
|
|
<entry>November 25, 2008</entry>
|
|
<entry>7.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701100</entry>
|
|
<entry>November 25, 2008</entry>
|
|
<entry>7.1-STABLE after 7.1-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701101</entry>
|
|
<entry>January 10, 2009</entry>
|
|
<entry>7.1-STABLE after <function>strndup</function>
|
|
merge.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701102</entry>
|
|
<entry>January 17, 2009</entry>
|
|
<entry>7.1-STABLE after cpuctl(4) support
|
|
added.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701103</entry>
|
|
<entry>February 7, 2009</entry>
|
|
<entry>7.1-STABLE after the merge of
|
|
multi-/no-IPv4/v6 jails.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701104</entry>
|
|
<entry>February 14, 2009</entry>
|
|
<entry>7.1-STABLE after the store of the suspension
|
|
owner in the struct mount, and introduction of
|
|
vfs_susp_clean method into the struct vfsops.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701105</entry>
|
|
<entry>March 12, 2009</entry>
|
|
<entry>7.1-STABLE after the incompatible change
|
|
to the kern.ipc.shmsegs sysctl to allow to allocate
|
|
larger SysV shared memory segments on 64bit
|
|
architectures.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>701106</entry>
|
|
<entry>March 14, 2009</entry>
|
|
<entry>7.1-STABLE after the merge of a fix for
|
|
POSIX semaphore wait operations.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702000</entry>
|
|
<entry>April 15, 2009</entry>
|
|
<entry>7.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702100</entry>
|
|
<entry>April 15, 2009</entry>
|
|
<entry>7.2-STABLE after 7.2-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702101</entry>
|
|
<entry>May 15, 2009</entry>
|
|
<entry>7.2-STABLE after ichsmb(4) was changed to
|
|
use left-adjusted slave addressing to match other
|
|
SMBus controller drivers.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702102</entry>
|
|
<entry>May 28, 2009</entry>
|
|
<entry>7.2-STABLE after MFC of the
|
|
<function>fdopendir</function> function.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702103</entry>
|
|
<entry>June 06, 2009</entry>
|
|
<entry>7.2-STABLE after MFC of PmcTools.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702104</entry>
|
|
<entry>July 14, 2009</entry>
|
|
<entry>7.2-STABLE after MFC of the
|
|
<function>closefrom</function> system call.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702105</entry>
|
|
<entry>July 31, 2009</entry>
|
|
<entry>7.2-STABLE after MFC of the SYSVIPC ABI
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>702106</entry>
|
|
<entry>September 14, 2009</entry>
|
|
<entry>7.2-STABLE after MFC of the x86 PAT
|
|
enhancements and addition of d_mmap_single() and
|
|
the scatter/gather list VM object type.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>703000</entry>
|
|
<entry>February 9, 2010</entry>
|
|
<entry>7.3-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>703100</entry>
|
|
<entry>February 9, 2010</entry>
|
|
<entry>7.3-STABLE after 7.3-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>704000</entry>
|
|
<entry>December 22, 2010</entry>
|
|
<entry>7.4-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>704100</entry>
|
|
<entry>December 22, 2010</entry>
|
|
<entry>7.4-STABLE after 7.4-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800000</entry>
|
|
<entry>October 11, 2007</entry>
|
|
<entry>8.0-CURRENT. Separating wide and single byte
|
|
ctype.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800001</entry>
|
|
<entry>October 16, 2007</entry>
|
|
<entry>8.0-CURRENT after libpcap 0.9.8 and tcpdump 3.9.8
|
|
import.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800002</entry>
|
|
<entry>October 21, 2007</entry>
|
|
<entry>8.0-CURRENT after renaming kthread_create()
|
|
and friends to kproc_create() etc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800003</entry>
|
|
<entry>October 24, 2007</entry>
|
|
<entry>8.0-CURRENT after ABI backwards compatibility
|
|
to the FreeBSD 4/5/6 versions of the PCIOCGETCONF,
|
|
PCIOCREAD and PCIOCWRITE IOCTLs was added, which
|
|
required the ABI of the PCIOCGETCONF IOCTL to be
|
|
broken again</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800004</entry>
|
|
<entry>November 12, 2007</entry>
|
|
<entry>8.0-CURRENT after agp(4) driver moved from
|
|
src/sys/pci to src/sys/dev/agp</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800005</entry>
|
|
<entry>December 4, 2007</entry>
|
|
<entry>8.0-CURRENT after
|
|
<ulink
|
|
url="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_mbuf.c#rev1.35">changes
|
|
to the jumbo frame allocator</ulink>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800006</entry>
|
|
<entry>December 7, 2007</entry>
|
|
<entry>8.0-CURRENT after the addition of callgraph
|
|
capture functionality to &man.hwpmc.4;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800007</entry>
|
|
<entry>December 25, 2007</entry>
|
|
<entry>8.0-CURRENT after kdb_enter() gains a "why"
|
|
argument.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800008</entry>
|
|
<entry>December 28, 2007</entry>
|
|
<entry>8.0-CURRENT after LK_EXCLUPGRADE option
|
|
removal.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800009</entry>
|
|
<entry>January 9, 2008</entry>
|
|
<entry>8.0-CURRENT after introduction of
|
|
&man.lockmgr.disown.9;</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800010</entry>
|
|
<entry>January 10, 2008</entry>
|
|
<entry>8.0-CURRENT after the &man.vn.lock.9; prototype
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800011</entry>
|
|
<entry>January 13, 2008</entry>
|
|
<entry>8.0-CURRENT after the &man.VOP.LOCK.9; and
|
|
&man.VOP.UNLOCK.9; prototype changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800012</entry>
|
|
<entry>January 19, 2008</entry>
|
|
<entry>8.0-CURRENT after introduction of
|
|
&man.lockmgr.recursed.9;, &man.BUF.RECURSED.9; and
|
|
&man.BUF.ISLOCKED.9; and the removal of
|
|
<function>BUF_REFCNT()</function>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800013</entry>
|
|
<entry>January 23, 2008</entry>
|
|
<entry>8.0-CURRENT after introduction of the
|
|
<quote>ASCII</quote> encoding.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800014</entry>
|
|
<entry>January 24, 2008</entry>
|
|
<entry>8.0-CURRENT after changing the prototype of
|
|
&man.lockmgr.9; and removal of
|
|
<function>lockcount()</function> and
|
|
<function>LOCKMGR_ASSERT()</function>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800015</entry>
|
|
<entry>January 26, 2008</entry>
|
|
<entry>8.0-CURRENT after extending the types
|
|
of the &man.fts.3; structures.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800016</entry>
|
|
<entry>February 1, 2008</entry>
|
|
<entry>8.0-CURRENT after adding an argument to
|
|
MEXTADD(9)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800017</entry>
|
|
<entry>February 6, 2008</entry>
|
|
<entry>8.0-CURRENT after the introduction of
|
|
LK_NODUP and LK_NOWITNESS options in the
|
|
&man.lockmgr.9; space.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800018</entry>
|
|
<entry>February 8, 2008</entry>
|
|
<entry>8.0-CURRENT after the addition of
|
|
m_collapse.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800019</entry>
|
|
<entry>February 9, 2008</entry>
|
|
<entry>8.0-CURRENT after the addition of current
|
|
working directory, root directory, and jail
|
|
directory support to the kern.proc.filedesc
|
|
sysctl.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800020</entry>
|
|
<entry>February 13, 2008</entry>
|
|
<entry>8.0-CURRENT after introduction of
|
|
&man.lockmgr.assert.9; and
|
|
<function>BUF_ASSERT</function> functions.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800021</entry>
|
|
<entry>February 15, 2008</entry>
|
|
<entry>8.0-CURRENT after introduction of
|
|
&man.lockmgr.args.9; and LK_INTERNAL flag
|
|
removal.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800022</entry>
|
|
<entry>(backed out)</entry>
|
|
<entry>8.0-CURRENT after changing the default system ar
|
|
to BSD &man.ar.1;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800023</entry>
|
|
<entry>February 25, 2008</entry>
|
|
<entry>8.0-CURRENT after changing the prototypes of
|
|
&man.lockstatus.9; and &man.VOP.ISLOCKED.9;, more
|
|
specifically retiring the
|
|
<literal>struct thread</literal> argument.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800024</entry>
|
|
<entry>March 1, 2008</entry>
|
|
<entry>8.0-CURRENT after axing out the
|
|
<function>lockwaiters</function> and
|
|
<function>BUF_LOCKWAITERS</function> functions,
|
|
changing the return value of
|
|
<function>brelvp</function> from void to int and
|
|
introducing new flags for &man.lockinit.9;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800025</entry>
|
|
<entry>March 8, 2008</entry>
|
|
<entry>8.0-CURRENT after adding F_DUP2FD command
|
|
to &man.fcntl.2;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800026</entry>
|
|
<entry>March 12, 2008</entry>
|
|
<entry>8.0-CURRENT after changing the priority parameter
|
|
to cv_broadcastpri such that 0 means no
|
|
priority.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800027</entry>
|
|
<entry>March 24, 2008</entry>
|
|
<entry>8.0-CURRENT after changing the bpf monitoring ABI
|
|
when zerocopy bpf buffers were added.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800028</entry>
|
|
<entry>March 26, 2008</entry>
|
|
<entry>8.0-CURRENT after adding l_sysid to struct
|
|
flock.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800029</entry>
|
|
<entry>March 28, 2008</entry>
|
|
<entry>8.0-CURRENT after reintegration of the
|
|
<function>BUF_LOCKWAITERS</function> function and the
|
|
addition of &man.lockmgr.waiters.9;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800030</entry>
|
|
<entry>April 1, 2008</entry>
|
|
<entry>8.0-CURRENT after the introduction of the
|
|
&man.rw.try.rlock.9; and &man.rw.try.wlock.9;
|
|
functions.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800031</entry>
|
|
<entry>April 6, 2008</entry>
|
|
<entry>8.0-CURRENT after the introduction of the
|
|
<function>lockmgr_rw</function> and
|
|
<function>lockmgr_args_rw</function>
|
|
functions.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800032</entry>
|
|
<entry>April 8, 2008</entry>
|
|
<entry>8.0-CURRENT after the implementation of the
|
|
openat and related syscalls, introduction of the
|
|
O_EXEC flag for the &man.open.2;, and providing the
|
|
corresponding linux compatibility syscalls.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800033</entry>
|
|
<entry>April 8, 2008</entry>
|
|
<entry>8.0-CURRENT after added &man.write.2; support for
|
|
&man.psm.4; in native operation level. Now arbitrary
|
|
commands can be written to
|
|
<devicename>/dev/psm%d</devicename> and status can be
|
|
read back from it.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800034</entry>
|
|
<entry>April 10, 2008</entry>
|
|
<entry>8.0-CURRENT after introduction of the
|
|
<function>memrchr</function> function.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800035</entry>
|
|
<entry>April 16, 2008</entry>
|
|
<entry>8.0-CURRENT after introduction of the
|
|
<function>fdopendir</function> function.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800036</entry>
|
|
<entry>April 20, 2008</entry>
|
|
<entry>8.0-CURRENT after switchover of 802.11 wireless
|
|
to multi-bss support (aka vaps).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800037</entry>
|
|
<entry>May 9, 2008</entry>
|
|
<entry>8.0-CURRENT after addition of multi routing
|
|
table support (aka setfib(1), setfib(2)).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800038</entry>
|
|
<entry>May 26, 2008</entry>
|
|
<entry>8.0-CURRENT after removal of netatm and
|
|
ISDN4BSD. Also, the addition of the
|
|
Compact C Type (CTF) tools.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800039</entry>
|
|
<entry>June 14, 2008</entry>
|
|
<entry>8.0-CURRENT after removal of sgtty.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800040</entry>
|
|
<entry>June 26, 2008</entry>
|
|
<entry>8.0-CURRENT with kernel NFS lockd client.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800041</entry>
|
|
<entry>July 22, 2008</entry>
|
|
<entry>8.0-CURRENT after addition of arc4random_buf(3)
|
|
and arc4random_uniform(3).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800042</entry>
|
|
<entry>August 8, 2008</entry>
|
|
<entry>8.0-CURRENT after addition of cpuctl(4).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800043</entry>
|
|
<entry>August 13, 2008</entry>
|
|
<entry>8.0-CURRENT after changing bpf(4) to use a
|
|
single device node, instead of device cloning.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800044</entry>
|
|
<entry>August 17, 2008</entry>
|
|
<entry>8.0-CURRENT after the commit of the first step of
|
|
the vimage project renaming global variables to be
|
|
virtualized with a V_ prefix with macros to map them
|
|
back to their global names.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800045</entry>
|
|
<entry>August 20, 2008</entry>
|
|
<entry>8.0-CURRENT after the integration of the
|
|
MPSAFE TTY layer, including changes to various
|
|
drivers and utilities that interact with it.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800046</entry>
|
|
<entry>September 8, 2008</entry>
|
|
<entry>8.0-CURRENT after the separation of the GDT
|
|
per CPU on amd64 architecture.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800047</entry>
|
|
<entry>September 10, 2008</entry>
|
|
<entry>8.0-CURRENT after removal of VSVTX, VSGID
|
|
and VSUID.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800048</entry>
|
|
<entry>September 16, 2008</entry>
|
|
<entry>8.0-CURRENT after converting the kernel NFS mount
|
|
code to accept individual mount options in the
|
|
nmount() iovec, not just one big
|
|
struct nfs_args.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800049</entry>
|
|
<entry>September 17, 2008</entry>
|
|
<entry>8.0-CURRENT after the removal of &man.suser.9;
|
|
and &man.suser.cred.9;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800050</entry>
|
|
<entry>October 20, 2008</entry>
|
|
<entry>8.0-CURRENT after buffer cache API
|
|
change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800051</entry>
|
|
<entry>October 23, 2008</entry>
|
|
<entry>8.0-CURRENT after the removal of the
|
|
&man.MALLOC.9; and &man.FREE.9; macros.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800052</entry>
|
|
<entry>October 28, 2008</entry>
|
|
<entry>8.0-CURRENT after the introduction of accmode_t
|
|
and renaming of VOP_ACCESS 'a_mode' argument
|
|
to 'a_accmode'.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800053</entry>
|
|
<entry>November 2, 2008</entry>
|
|
<entry>8.0-CURRENT after the prototype change of
|
|
&man.vfs.busy.9; and the introduction of its
|
|
MBF_NOWAIT and MBF_MNTLSTLOCK flags.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800054</entry>
|
|
<entry>November 22, 2008</entry>
|
|
<entry>8.0-CURRENT after the addition of buf_ring,
|
|
memory barriers and ifnet functions to facilitate
|
|
multiple hardware transmit queues for cards that
|
|
support them, and a lockless ring-buffer
|
|
implementation to enable drivers to more efficiently
|
|
manage queuing of packets.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800055</entry>
|
|
<entry>November 27, 2008</entry>
|
|
<entry>8.0-CURRENT after the addition of Intel™
|
|
Core, Core2, and Atom support to
|
|
&man.hwpmc.4;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800056</entry>
|
|
<entry>November 29, 2008</entry>
|
|
<entry>8.0-CURRENT after the introduction of
|
|
multi-/no-IPv4/v6 jails.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800057</entry>
|
|
<entry>December 1, 2008</entry>
|
|
<entry>8.0-CURRENT after the switch to the
|
|
ath hal source code.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800058</entry>
|
|
<entry>December 12, 2008</entry>
|
|
<entry>8.0-CURRENT after the introduction of
|
|
the VOP_VPTOCNP operation.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800059</entry>
|
|
<entry>December 15, 2008</entry>
|
|
<entry>8.0-CURRENT incorporates the
|
|
new arp-v2 rewrite.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800060</entry>
|
|
<entry>December 19, 2008</entry>
|
|
<entry>8.0-CURRENT after the addition of makefs.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800061</entry>
|
|
<entry>January 15, 2009</entry>
|
|
<entry>8.0-CURRENT after TCP Appropriate Byte
|
|
Counting.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800062</entry>
|
|
<entry>January 28, 2009</entry>
|
|
<entry>8.0-CURRENT after removal of minor(),
|
|
minor2unit(), unit2minor(), etc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800063</entry>
|
|
<entry>February 18, 2009</entry>
|
|
<entry>8.0-CURRENT after GENERIC config change to use
|
|
the USB2 stack, but also the addition of
|
|
fdevname(3).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800064</entry>
|
|
<entry>February 23, 2009</entry>
|
|
<entry>8.0-CURRENT after the USB2 stack is moved to and
|
|
replaces dev/usb.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800065</entry>
|
|
<entry>February 26, 2009</entry>
|
|
<entry>8.0-CURRENT after the renaming of all functions
|
|
in libmp(3).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800066</entry>
|
|
<entry>February 27, 2009</entry>
|
|
<entry>8.0-CURRENT after changing USB devfs handling and
|
|
layout.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800067</entry>
|
|
<entry>February 28, 2009</entry>
|
|
<entry>8.0-CURRENT after adding getdelim(), getline(),
|
|
stpncpy(), strnlen(), wcsnlen(), wcscasecmp(), and
|
|
wcsncasecmp().</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800068</entry>
|
|
<entry>March 2, 2009</entry>
|
|
<entry>8.0-CURRENT after renaming the ushub devclass to
|
|
uhub.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800069</entry>
|
|
<entry>March 9, 2009</entry>
|
|
<entry>8.0-CURRENT after libusb20.so.1 was renamed to
|
|
libusb.so.1.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800070</entry>
|
|
<entry>March 9, 2009</entry>
|
|
<entry>8.0-CURRENT after merging IGMPv3 and
|
|
Source-Specific Multicast (SSM) to the IPv4
|
|
stack.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800071</entry>
|
|
<entry>March 14, 2009</entry>
|
|
<entry>8.0-CURRENT after gcc was patched to use C99
|
|
inline semantics in c99 and gnu99 mode.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800072</entry>
|
|
<entry>March 15, 2009</entry>
|
|
<entry>8.0-CURRENT after the IFF_NEEDSGIANT flag has
|
|
been removed; non-MPSAFE network device drivers are no
|
|
longer supported.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800073</entry>
|
|
<entry>March 18, 2009</entry>
|
|
<entry>8.0-CURRENT after the dynamic string token
|
|
substitution has been implemented for rpath and needed
|
|
paths.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800074</entry>
|
|
<entry>March 24, 2009</entry>
|
|
<entry>8.0-CURRENT after tcpdump 4.0.0 and
|
|
libpcap 1.0.0 import.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800075</entry>
|
|
<entry>April 6, 2009</entry>
|
|
<entry>8.0-CURRENT after layout of structs vnet_net,
|
|
vnet_inet and vnet_ipfw has been changed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800076</entry>
|
|
<entry>April 9, 2009</entry>
|
|
<entry>8.0-CURRENT after adding delay profiles in
|
|
dummynet.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800077</entry>
|
|
<entry>April 14, 2009</entry>
|
|
<entry>8.0-CURRENT after removing VOP_LEASE() and
|
|
vop_vector.vop_lease.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800078</entry>
|
|
<entry>April 15, 2009</entry>
|
|
<entry>8.0-CURRENT after struct rt_weight fields have
|
|
been added to struct rt_metrics and struct
|
|
rt_metrics_lite, changing the layout of struct
|
|
rt_metrics_lite. A bump to RTM_VERSION was made, but
|
|
backed out.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800079</entry>
|
|
<entry>April 15, 2009</entry>
|
|
<entry>8.0-CURRENT after struct llentry pointers are
|
|
added to struct route and struct route_in6.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800080</entry>
|
|
<entry>April 15, 2009</entry>
|
|
<entry>8.0-CURRENT after layout of struct inpcb has been
|
|
changed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800081</entry>
|
|
<entry>April 19, 2009</entry>
|
|
<entry>8.0-CURRENT after the layout of struct
|
|
malloc_type has been changed.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800082</entry>
|
|
<entry>April 21, 2009</entry>
|
|
<entry>8.0-CURRENT after the layout of struct ifnet has
|
|
changed, and with if_ref() and if_rele() ifnet
|
|
refcounting.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800083</entry>
|
|
<entry>April 22, 2009</entry>
|
|
<entry>8.0-CURRENT after the implementation of a
|
|
low-level Bluetooth HCI API.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800084</entry>
|
|
<entry>April 29, 2009</entry>
|
|
<entry>8.0-CURRENT after IPv6 SSM and MLDv2
|
|
changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800085</entry>
|
|
<entry>April 30, 2009</entry>
|
|
<entry>8.0-CURRENT after enabling support for
|
|
VIMAGE kernel builds with one active image.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800086</entry>
|
|
<entry>May 8, 2009</entry>
|
|
<entry>8.0-CURRENT after adding support for input lines
|
|
of arbitrarily length in patch(1).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800087</entry>
|
|
<entry>May 11, 2009</entry>
|
|
<entry>8.0-CURRENT after some VFS KPI changes. The
|
|
thread argument has been removed from the FSD parts of
|
|
the VFS. <function>VFS_*</function> functions do not
|
|
need the context any more because it always refers to
|
|
<varname>curthread</varname>. In some special cases,
|
|
the old behavior is retained.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800088</entry>
|
|
<entry>May 20, 2009</entry>
|
|
<entry>8.0-CURRENT after net80211 monitor mode
|
|
changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800089</entry>
|
|
<entry>May 23, 2009</entry>
|
|
<entry>8.0-CURRENT after adding UDP control block
|
|
support.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800090</entry>
|
|
<entry>May 23, 2009</entry>
|
|
<entry>8.0-CURRENT after virtualizing interface
|
|
cloning.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800091</entry>
|
|
<entry>May 27, 2009</entry>
|
|
<entry>8.0-CURRENT after adding hierarchical jails
|
|
and removing global securelevel.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800092</entry>
|
|
<entry>May 29, 2009</entry>
|
|
<entry>8.0-CURRENT after changing
|
|
<function>sx_init_flags()</function> KPI. The
|
|
<constant>SX_ADAPTIVESPIN</constant> is retired and a
|
|
new <constant>SX_NOADAPTIVE</constant> flag is
|
|
introduced in order to handle the reversed
|
|
logic.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800093</entry>
|
|
<entry>May 29, 2009</entry>
|
|
<entry>8.0-CURRENT after adding mnt_xflag to
|
|
struct mount.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800094</entry>
|
|
<entry>May 30, 2009</entry>
|
|
<entry>8.0-CURRENT after adding
|
|
&man.VOP.ACCESSX.9;.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800095</entry>
|
|
<entry>May 30, 2009</entry>
|
|
<entry>8.0-CURRENT after changing the polling KPI.
|
|
The polling handlers now return the number of packets
|
|
processed. A new
|
|
<constant>IFCAP_POLLING_NOCOUNT</constant> is also
|
|
introduced to specify that the return value is
|
|
not significant and the counting should be
|
|
skipped.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800096</entry>
|
|
<entry>June 1, 2009</entry>
|
|
<entry>8.0-CURRENT after updating to the new netisr
|
|
implementation and after changing the way we
|
|
store and access FIBs.</entry>
|
|
<!--
|
|
Had been 96 and 97 but were folded because we are
|
|
running out of numbers.
|
|
-->
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800097</entry>
|
|
<entry>June 8, 2009</entry>
|
|
<entry>8.0-CURRENT after the introduction of vnet
|
|
destructor hooks and infrastructure.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800097</entry>
|
|
<entry>June 11, 2009</entry>
|
|
<entry>8.0-CURRENT after the introduction of netgraph
|
|
outbound to inbound path call detection and queuing,
|
|
which also changed the layout of struct
|
|
thread.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800098</entry>
|
|
<entry>June 14, 2009</entry>
|
|
<entry>8.0-CURRENT after OpenSSL 0.9.8k import.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800099</entry>
|
|
<entry>June 22, 2009</entry>
|
|
<entry>8.0-CURRENT after NGROUPS update and moving
|
|
route virtualization into its own VImage
|
|
module.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800100</entry>
|
|
<entry>June 24, 2009</entry>
|
|
<entry>8.0-CURRENT after SYSVIPC ABI change.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800101</entry>
|
|
<entry>June 29, 2009</entry>
|
|
<entry>8.0-CURRENT after the removal of the
|
|
/dev/net/* per-interface character
|
|
devices.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800102</entry>
|
|
<entry>July 12, 2009</entry>
|
|
<entry>8.0-CURRENT after padding was added to
|
|
struct sackhint, struct tcpcb, and struct
|
|
tcpstat.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800103</entry>
|
|
<entry>July 13, 2009</entry>
|
|
<entry>8.0-CURRENT after replacing struct tcpopt
|
|
with struct toeopt in the TOE driver interface
|
|
to the TCP syncache.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800104</entry>
|
|
<entry>July 14, 2009</entry>
|
|
<entry>8.0-CURRENT after the addition of the
|
|
linker-set based per-vnet allocator.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800105</entry>
|
|
<entry>July 19, 2009</entry>
|
|
<entry>8.0-CURRENT after version bump for all
|
|
shared libraries that do not have symbol versioning
|
|
turned on.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800106</entry>
|
|
<entry>July 24, 2009</entry>
|
|
<entry>8.0-CURRENT after introduction of OBJT_SG
|
|
VM object type.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800107</entry>
|
|
<entry>August 2, 2009</entry>
|
|
<entry>8.0-CURRENT after making the newbus subsystem
|
|
Giant free by adding the newbus sxlock and
|
|
8.0-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800108</entry>
|
|
<entry>November 21, 2009</entry>
|
|
<entry>8.0-STABLE after implementing EVFILT_USER kevent
|
|
filter.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800500</entry>
|
|
<entry>January 7, 2010</entry>
|
|
<entry>8.0-STABLE after
|
|
<literal>__FreeBSD_version</literal> bump to make
|
|
<command>pkg_add -r</command> use
|
|
packages-8-stable.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800501</entry>
|
|
<entry>January 24, 2010</entry>
|
|
<entry>8.0-STABLE after change of the
|
|
<function>scandir(3)</function> and
|
|
<function>alphasort(3)</function> prototypes to
|
|
conform to SUSv4.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800502</entry>
|
|
<entry>January 31, 2010</entry>
|
|
<entry>8.0-STABLE after addition of
|
|
<function>sigpause(3)</function>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800503</entry>
|
|
<entry>February 25, 2010</entry>
|
|
<entry>8.0-STABLE after addition of SIOCGIFDESCR
|
|
and SIOCSIFDESCR ioctls to network interfaces. These
|
|
ioctl can be used to manipulate interface description,
|
|
as inspired by OpenBSD.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800504</entry>
|
|
<entry>March 1, 2010</entry>
|
|
<entry>8.0-STABLE after MFC of importing x86emu, a
|
|
software emulator for real mode x86 CPU from
|
|
OpenBSD.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>800505</entry>
|
|
<entry>May 18, 2010</entry>
|
|
<entry>8.0-STABLE after MFC of adding liblzma, xz,
|
|
xzdec, and lzmainfo.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>801000</entry>
|
|
<entry>June 14, 2010</entry>
|
|
<entry>8.1-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>801500</entry>
|
|
<entry>June 14, 2010</entry>
|
|
<entry>8.1-STABLE after 8.1-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>801501</entry>
|
|
<entry>November 3, 2010</entry>
|
|
<entry>8.1-STABLE after KBI change in struct sysentvec,
|
|
and implementation of PL_FLAG_SCE/SCX/EXEC/SI and
|
|
pl_siginfo for ptrace(PT_LWPINFO) .</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802000</entry>
|
|
<entry>December 22, 2010</entry>
|
|
<entry>8.2-RELEASE</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802500</entry>
|
|
<entry>December 22, 2010</entry>
|
|
<entry>8.2-STABLE after 8.2-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802501</entry>
|
|
<entry>February 28, 2011</entry>
|
|
<entry>8.2-STABLE after merging DTrace changes,
|
|
including support for userland tracing.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802502</entry>
|
|
<entry>March 6, 2011</entry>
|
|
<entry>8.2-STABLE after merging log2 and log2f
|
|
into libm.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802503</entry>
|
|
<entry>May 1, 2011</entry>
|
|
<entry>8.2-STABLE after upgrade of the gcc to the last
|
|
GPLv2 version from the FSF gcc-4_2-branch.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802504</entry>
|
|
<entry>May 28, 2011</entry>
|
|
<entry>8.2-STABLE after introduction of the KPI and
|
|
supporting infrastructure for modular congestion
|
|
control.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802505</entry>
|
|
<entry>May 28, 2011</entry>
|
|
<entry>8.2-STABLE after introduction of Hhook and Khelp
|
|
KPIs.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802506</entry>
|
|
<entry>May 28, 2011</entry>
|
|
<entry>8.2-STABLE after addition of OSD to struct
|
|
tcpcb.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802507</entry>
|
|
<entry>June 6, 2011</entry>
|
|
<entry>8.2-STABLE after ZFS v28 import.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802508</entry>
|
|
<entry>June 8, 2011</entry>
|
|
<entry>8.2-STABLE after removal of the schedtail event
|
|
handler and addition of the sv_schedtail method to
|
|
struct sysvec.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802509</entry>
|
|
<entry>July 14, 2011</entry>
|
|
<entry>8.2-STABLE after merging the SSSE3 support
|
|
into binutils.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802510</entry>
|
|
<entry>July 19, 2011</entry>
|
|
<entry>8.2-STABLE after addition of
|
|
RFTSIGZMB flag for
|
|
<function>rfork(2)</function>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802511</entry>
|
|
<entry>September 9, 2011</entry>
|
|
<entry>8.2-STABLE after addition of automatic detection
|
|
of USB mass storage devices which do not support the
|
|
no synchronize cache SCSI command.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802512</entry>
|
|
<entry>September 10, 2011</entry>
|
|
<entry>8.2-STABLE after merging of
|
|
re-factoring of auto-quirk.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802513</entry>
|
|
<entry>October 25, 2011</entry>
|
|
<entry>8.2-STABLE after merging of the MAP_PREFAULT_READ
|
|
flag to <function>mmap(2)</function>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802514</entry>
|
|
<entry>November 16, 2011</entry>
|
|
<entry>8.2-STABLE after merging of
|
|
addition of posix_fallocate(2) syscall.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802515</entry>
|
|
<entry>January 6, 2012</entry>
|
|
<entry>8.2-STABLE after merging of addition of the
|
|
posix_fadvise(2) system call.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802516</entry>
|
|
<entry>January 16, 2012</entry>
|
|
<entry>8.2-STABLE after merging gperf 3.0.3</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>802517</entry>
|
|
<entry>February 15, 2012</entry>
|
|
<entry>8.2-STABLE after introduction of the new
|
|
extensible sysctl(3) interface NET_RT_IFLISTL
|
|
to query address lists (rev
|
|
<svnref>231769</svnref>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>803000</entry>
|
|
<entry>March 3, 2012</entry>
|
|
<entry>8.3-RELEASE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>803500</entry>
|
|
<entry>March 3, 2012</entry>
|
|
<entry>8.3-STABLE after branching releng/8.3
|
|
(RELENG_8_3).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900000</entry>
|
|
<entry>August 22, 2009</entry>
|
|
<entry>9.0-CURRENT.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900001</entry>
|
|
<entry>September 8, 2009</entry>
|
|
<entry>9.0-CURRENT after importing x86emu, a software
|
|
emulator for real mode x86 CPU from OpenBSD.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900002</entry>
|
|
<entry>September 23, 2009</entry>
|
|
<entry>9.0-CURRENT after implementing the EVFILT_USER
|
|
kevent filter functionality.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900003</entry>
|
|
<entry>December 2, 2009</entry>
|
|
<entry>9.0-CURRENT after addition of
|
|
<function>sigpause(3)</function> and PIE
|
|
support in csu.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900004</entry>
|
|
<entry>December 6, 2009</entry>
|
|
<entry>9.0-CURRENT after addition of libulog and its
|
|
libutempter compatibility interface.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900005</entry>
|
|
<entry>December 12, 2009</entry>
|
|
<entry>9.0-CURRENT after addition of
|
|
<function>sleepq_sleepcnt()</function>, which can be
|
|
used to query the number of waiters on a specific
|
|
waiting queue.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900006</entry>
|
|
<entry>January 4, 2010</entry>
|
|
<entry>9.0-CURRENT after change of the
|
|
<function>scandir(3)</function> and
|
|
<function>alphasort(3)</function> prototypes to
|
|
conform to SUSv4.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900007</entry>
|
|
<entry>January 13, 2010</entry>
|
|
<entry>9.0-CURRENT after the removal of utmp(5) and
|
|
the addition of utmpx (see
|
|
<function>getutxent(3)</function>) for improved
|
|
logging of user logins and system events.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900008</entry>
|
|
<entry>January 20, 2010</entry>
|
|
<entry>9.0-CURRENT after the import of BSDL bc/dc and
|
|
the deprecation of GNU bc/dc.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900009</entry>
|
|
<entry>January 26, 2010</entry>
|
|
<entry>9.0-CURRENT after the addition of SIOCGIFDESCR
|
|
and SIOCSIFDESCR ioctls to network interfaces. These
|
|
ioctl can be used to manipulate interface description,
|
|
as inspired by OpenBSD.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900010</entry>
|
|
<entry>March 22, 2010</entry>
|
|
<entry>9.0-CURRENT after the import of zlib
|
|
1.2.4.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900011</entry>
|
|
<entry>April 24, 2010</entry>
|
|
<entry>9.0-CURRENT after adding soft-updates
|
|
journalling.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900012</entry>
|
|
<entry>May 10, 2010</entry>
|
|
<entry>9.0-CURRENT after adding liblzma, xz, xzdec,
|
|
and lzmainfo.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900013</entry>
|
|
<entry>May 24, 2010</entry>
|
|
<entry>9.0-CURRENT after bringing in USB fixes for
|
|
linux(4).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900014</entry>
|
|
<entry>June 10, 2010</entry>
|
|
<entry>9.0-CURRENT after adding Clang.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900015</entry>
|
|
<entry>July 22, 2010</entry>
|
|
<entry>9.0-CURRENT after the import of BSD grep.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900016</entry>
|
|
<entry>July 28, 2010</entry>
|
|
<entry>9.0-CURRENT after adding mti_zone to
|
|
struct malloc_type_internal.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900017</entry>
|
|
<entry>August 23, 2010</entry>
|
|
<entry>9.0-CURRENT after changing back default grep to
|
|
GNU grep and adding WITH_BSD_GREP knob.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900018</entry>
|
|
<entry>August 24, 2010</entry>
|
|
<entry>9.0-CURRENT after the
|
|
<function>pthread_kill(3)</function> -generated signal
|
|
is identified as SI_LWP in si_code. Previously,
|
|
si_code was SI_USER.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900019</entry>
|
|
<entry>August 28, 2010</entry>
|
|
<entry>9.0-CURRENT after addition of the
|
|
MAP_PREFAULT_READ flag to
|
|
<function>mmap(2)</function>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900020</entry>
|
|
<entry>September 9, 2010</entry>
|
|
<entry>9.0-CURRENT after adding drain functionality
|
|
to sbufs, which also changed the layout of
|
|
struct sbuf.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900021</entry>
|
|
<entry>September 13, 2010</entry>
|
|
<entry>9.0-CURRENT after DTrace has grown support
|
|
for userland tracing.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900022</entry>
|
|
<entry>October 2, 2010</entry>
|
|
<entry>9.0-CURRENT after addition of the BSDL man
|
|
utilities and retirement of GNU/GPL man
|
|
utilities.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900023</entry>
|
|
<entry>October 11, 2010</entry>
|
|
<entry>9.0-CURRENT after updating xz to git 20101010
|
|
snapshot.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900024</entry>
|
|
<entry>November 11, 2010</entry>
|
|
<entry>9.0-CURRENT after libgcc.a was replaced
|
|
by libcompiler_rt.a.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900025</entry>
|
|
<entry>November 12, 2010</entry>
|
|
<entry>9.0-CURRENT after the introduction of the
|
|
modularised congestion control.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900026</entry>
|
|
<entry>November 30, 2010</entry>
|
|
<entry>9.0-CURRENT after the introduction of Serial
|
|
Management Protocol (SMP) passthrough and the
|
|
XPT_SMP_IO and XPT_GDEV_ADVINFO CAM CCBs.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900027</entry>
|
|
<entry>December 5, 2010</entry>
|
|
<entry>9.0-CURRENT after the addition of log2 to
|
|
libm.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900028</entry>
|
|
<entry>December 21, 2010</entry>
|
|
<entry>9.0-CURRENT after the addition of the Hhook
|
|
(Helper Hook), Khelp (Kernel Helpers) and Object
|
|
Specific Data (OSD) KPIs.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900029</entry>
|
|
<entry>December 28, 2010</entry>
|
|
<entry>9.0-CURRENT after the modification of the TCP
|
|
stack to allow Khelp modules to interact with it via
|
|
helper hook points and store per-connection data in
|
|
the TCP control block.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900030</entry>
|
|
<entry>January 12, 2011</entry>
|
|
<entry>9.0-CURRENT after the update of libdialog to
|
|
version 20100428.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900031</entry>
|
|
<entry>February 7, 2011</entry>
|
|
<entry>9.0-CURRENT after the addition of
|
|
<function>pthread_getthreadid_np(3)</function>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900032</entry>
|
|
<entry>February 8, 2011</entry>
|
|
<entry>9.0-CURRENT after the removal of the uio_yield
|
|
prototype and symbol.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900033</entry>
|
|
<entry>February 18, 2011</entry>
|
|
<entry>9.0-CURRENT after the update of binutils to
|
|
version 2.17.50.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900034</entry>
|
|
<entry>March 8, 2011</entry>
|
|
<entry>9.0-CURRENT after the struct sysvec
|
|
(sv_schedtail) changes.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900035</entry>
|
|
<entry>March 29, 2011</entry>
|
|
<entry>9.0-CURRENT after the update of base gcc and
|
|
libstdc++ to the last GPLv2 licensed revision.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900036</entry>
|
|
<entry>April 18, 2011</entry>
|
|
<entry>9.0-CURRENT after the removal of libobjc and
|
|
Objective-C support from the base system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900037</entry>
|
|
<entry>May 13, 2011</entry>
|
|
<entry>9.0-CURRENT after importing the libprocstat(3)
|
|
library and fuser(1) utility to the base
|
|
system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900038</entry>
|
|
<entry>May 22, 2011</entry>
|
|
<entry>9.0-CURRENT after adding a lock flag argument to
|
|
VFS_FHTOVP(9).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900039</entry>
|
|
<entry>June 28, 2011</entry>
|
|
<entry>9.0-CURRENT after importing pf from OpenBSD
|
|
4.5.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900040</entry>
|
|
<entry>July 19, 2011</entry>
|
|
<entry>Increase default MAXCPU for FreeBSD to 64 on
|
|
amd64 and ia64 and to 128 for XLP (mips).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900041</entry>
|
|
<entry>August 13, 2011</entry>
|
|
<entry>9.0-CURRENT after the implementation of Capsicum
|
|
capabilities; fget(9) gains a rights argument.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900042</entry>
|
|
<entry>August 28, 2011</entry>
|
|
<entry>Bump shared libraries' version numbers for
|
|
libraries whose ABI has changed in preparation for
|
|
9.0.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900043</entry>
|
|
<entry>September 2, 2011</entry>
|
|
<entry>Add automatic detection of USB mass storage
|
|
devices which do not support the no synchronize cache
|
|
SCSI command.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900044</entry>
|
|
<entry>September 10, 2011</entry>
|
|
<entry>Re-factor auto-quirk. 9.0-RELEASE.</entry>
|
|
</row>
|
|
|
|
<!-- Note: at one point 900045 was documented as follows, even though
|
|
it was never committed:
|
|
<row>
|
|
<entry>900045</entry>
|
|
<entry>Oct 13, 2011</entry>
|
|
<entry>All non-compatibility system call entry points
|
|
have been prefixed with sys_.</entry>
|
|
</row>
|
|
-->
|
|
|
|
<row>
|
|
<entry>900045</entry> <entry>January 2, 2012</entry>
|
|
<entry>9-CURRENT after MFC of true/false from
|
|
1000002.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900500</entry>
|
|
<entry>January 2, 2012</entry>
|
|
<entry>9.0-STABLE.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900501</entry>
|
|
<entry>January 6, 2012</entry>
|
|
<entry>9.0-STABLE after merging of addition of the
|
|
posix_fadvise(2) system call.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900502</entry>
|
|
<entry>January 16, 2012</entry>
|
|
<entry>9.0-STABLE after merging gperf 3.0.3</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900503</entry>
|
|
<entry>February 15, 2012</entry>
|
|
<entry>9.0-STABLE after introduction of the new
|
|
extensible sysctl(3) interface NET_RT_IFLISTL
|
|
to query address lists (rev
|
|
<svnref>231768</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900504</entry>
|
|
<entry>March 3, 2012</entry>
|
|
<entry>9.0-STABLE after changes related to mounting
|
|
of filesystem inside a jail (rev
|
|
<svnref>232728</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>900505</entry>
|
|
<entry>March 13, 2012</entry>
|
|
<entry>9.0-STABLE after introduction of new tcp(4)
|
|
socket options: TCP_KEEPINIT, TCP_KEEPIDLE,
|
|
TCP_KEEPINTVL, and TCP_KEEPCNT (rev
|
|
<svnref>232945</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000000</entry>
|
|
<entry>September 26, 2011</entry>
|
|
<entry>10.0-CURRENT.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000001</entry>
|
|
<entry>November 4, 2011</entry>
|
|
<entry>10-CURRENT after addition of the posix_fadvise(2)
|
|
system call.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000002</entry>
|
|
<entry>December 12, 2011</entry>
|
|
<entry>10-CURRENT after defining boolean true/false in
|
|
sys/types.h, sizeof(bool) may have changed (rev
|
|
<svnref>228444</svnref>). 10-CURRENT after xlocale.h
|
|
was introduced (rev
|
|
<svnref>227753</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000003</entry>
|
|
<entry>December 16, 2011</entry>
|
|
<entry>10-CURRENT after major changes to carp(4),
|
|
changing size of struct in_aliasreq,
|
|
struct in6_aliasreq (rev <svnref>228571</svnref>)
|
|
and straitening arguments check of SIOCAIFADDR (rev
|
|
<svnref>228574</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000004</entry>
|
|
<entry>January 1, 2012</entry>
|
|
<entry>10-CURRENT after the removal of skpc(9) and the
|
|
addition of memcchr(9) (rev
|
|
<svnref>229200</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000005</entry>
|
|
<entry>January 16, 2012</entry>
|
|
<entry>10-CURRENT after the removal of support for
|
|
SIOCSIFADDR, SIOCSIFNETMASK, SIOCSIFBRDADDR,
|
|
SIOCSIFDSTADDR ioctls (rev
|
|
<svnref>230207</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000006</entry>
|
|
<entry>January 26, 2012</entry>
|
|
<entry>10-CURRENT after introduction of read capacity
|
|
data asynchronous notification in the cam(4) layer
|
|
(rev <svnref>230590</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000007</entry>
|
|
<entry>February 5, 2012</entry>
|
|
<entry>10-CURRENT after introduction of new tcp(4)
|
|
socket options: TCP_KEEPINIT, TCP_KEEPIDLE,
|
|
TCP_KEEPINTVL, and TCP_KEEPCNT (rev
|
|
<svnref>231025</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000008</entry>
|
|
<entry>February 11, 2012</entry>
|
|
<entry>10-CURRENT after introduction of the new
|
|
extensible sysctl(3) interface NET_RT_IFLISTL
|
|
to query address lists (rev
|
|
<svnref>231505</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000009</entry>
|
|
<entry>February 25, 2012</entry>
|
|
<entry>10-CURRENT after import of libarchive 3.0.3
|
|
(rev <svnref>232153</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000010</entry>
|
|
<entry>March 31, 2012</entry>
|
|
<entry>10-CURRENT after xlocale cleanup (rev
|
|
<svnref>233757</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000011</entry>
|
|
<entry>April 16, 2012</entry>
|
|
<entry>10-CURRENT import of LLVM/Clang 3.1 trunk r154661
|
|
(rev <svnref>234353</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000012</entry>
|
|
<entry>May 2, 2012</entry>
|
|
<entry>10-CURRENT jemalloc import
|
|
(rev <svnref>234924</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000013</entry>
|
|
<entry>May 22, 2012</entry>
|
|
<entry>10-CURRENT after byacc import
|
|
(rev <svnref>235788</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000014</entry>
|
|
<entry>June 27, 2012</entry>
|
|
<entry>10-CURRENT after BSD sort becoming the default
|
|
sort (rev <svnref>237629</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>1000015</entry>
|
|
<entry>July 12, 2012</entry>
|
|
<entry>10-CURRENT after import of OpenSSL 1.0.1c
|
|
(rev <svnref>238405</svnref>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>(not changed)</entry>
|
|
<entry>July 13, 2012</entry>
|
|
<entry>10-CURRENT after the fix for LLVM/Clang 3.1
|
|
regression (rev <svnref>238429</svnref>).</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<note>
|
|
<para>Note that 2.2-STABLE sometimes identifies itself as
|
|
<quote>2.2.5-STABLE</quote> after the 2.2.5-RELEASE. The
|
|
pattern used to be year followed by the month, but we
|
|
decided to change it to a more straightforward major/minor
|
|
system starting from 2.2. This is because the parallel
|
|
development on several branches made it infeasible to
|
|
classify the releases simply by their real release dates.
|
|
If you are making a port now, you do not have to worry about
|
|
old -CURRENTs; they are listed here just for your
|
|
reference.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-after-port-mk">
|
|
<title>Writing Something After
|
|
<filename>bsd.port.mk</filename></title>
|
|
|
|
<para>Do not write anything after the <literal>.include
|
|
<bsd.port.mk></literal> line. It usually can be
|
|
avoided by including <filename>bsd.port.pre.mk</filename>
|
|
somewhere in the middle of your <filename>Makefile</filename>
|
|
and <filename>bsd.port.post.mk</filename> at the end.</para>
|
|
|
|
<note>
|
|
<para>Include either the
|
|
<filename>bsd.port.pre.mk</filename>/<filename>bsd.port.post.mk</filename>
|
|
pair or <filename>bsd.port.mk</filename> only; do not mix
|
|
these two usages.</para>
|
|
</note>
|
|
|
|
<para><filename>bsd.port.pre.mk</filename> only defines a few
|
|
variables, which can be used in tests in the
|
|
<filename>Makefile</filename>,
|
|
<filename>bsd.port.post.mk</filename> defines the rest.</para>
|
|
|
|
<para>Here are some important variables defined in
|
|
<filename>bsd.port.pre.mk</filename> (this is not the complete
|
|
list, please read <filename>bsd.port.mk</filename> for the
|
|
complete list).</para>
|
|
|
|
<informaltable frame="none" pgwide="0">
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Variable</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry><makevar>ARCH</makevar></entry>
|
|
<entry>The architecture as returned by <command>uname
|
|
-m</command> (e.g., <literal>i386</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>OPSYS</makevar></entry>
|
|
<entry>The operating system type, as returned by
|
|
<command>uname -s</command> (e.g.,
|
|
<literal>FreeBSD</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>OSREL</makevar></entry>
|
|
<entry>The release version of the operating system
|
|
(e.g., <literal>2.1.5</literal> or
|
|
<literal>2.2.7</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>OSVERSION</makevar></entry>
|
|
<entry>The numeric version of the operating system; the
|
|
same as <link
|
|
linkend="freebsd-versions"><literal>__FreeBSD_version</literal></link>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>LOCALBASE</makevar></entry>
|
|
<entry>The base of the <quote>local</quote> tree (e.g.,
|
|
<literal>/usr/local/</literal>)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><makevar>PREFIX</makevar></entry>
|
|
<entry>Where the port installs itself (see <link
|
|
linkend="porting-prefix">more on
|
|
<makevar>PREFIX</makevar></link>).</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<note>
|
|
<para>If you have to define the variables
|
|
<makevar>USE_IMAKE</makevar> or
|
|
<makevar>MASTERDIR</makevar>, do so before including
|
|
<filename>bsd.port.pre.mk</filename>.</para>
|
|
</note>
|
|
|
|
<para>Here are some examples of things you can write after
|
|
<filename>bsd.port.pre.mk</filename>:</para>
|
|
|
|
<programlisting># no need to compile lang/perl5 if perl5 is already in system
|
|
.if ${OSVERSION} > 300003
|
|
BROKEN= perl is in system
|
|
.endif
|
|
|
|
# only one shlib version number for ELF
|
|
.if ${PORTOBJFORMAT} == "elf"
|
|
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}
|
|
.else
|
|
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
|
|
.endif
|
|
|
|
# software already makes link for ELF, but not for a.out
|
|
post-install:
|
|
.if ${PORTOBJFORMAT} == "aout"
|
|
${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
|
|
.endif</programlisting>
|
|
|
|
<para>You did remember to use tab instead of spaces after
|
|
<literal>BROKEN=</literal> and
|
|
<literal>TCL_LIB_FILE=</literal>, did you not?
|
|
<!-- smiley -->:-).</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-sh-exec">
|
|
<title>Use the <function>exec</function> Statement in Wrapper
|
|
Scripts</title>
|
|
|
|
<para>If the port installs a shell script whose purpose is to
|
|
launch another program, and if launching that program is the
|
|
last action performed by the script, make sure to launch the
|
|
program using the <function>exec</function> statement, for
|
|
instance:</para>
|
|
|
|
<programlisting>#!/bin/sh
|
|
exec %%LOCALBASE%%/bin/java -jar %%DATADIR%%/foo.jar "$@"</programlisting>
|
|
|
|
<para>The <function>exec</function> statement replaces the shell
|
|
process with the specified program. If
|
|
<function>exec</function> is omitted, the shell process
|
|
remains in memory while the program is executing, and
|
|
needlessly consumes system resources.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-rational">
|
|
<title>Do Things Rationally</title>
|
|
|
|
<para>The <filename>Makefile</filename> should do things simply
|
|
and reasonably. If you can make it a couple of lines shorter
|
|
or more readable, then do so. Examples include using a make
|
|
<literal>.if</literal> construct instead of a shell
|
|
<literal>if</literal> construct, not redefining
|
|
<maketarget>do-extract</maketarget> if you can redefine
|
|
<makevar>EXTRACT*</makevar> instead, and using
|
|
<makevar>GNU_CONFIGURE</makevar> instead of
|
|
<literal>CONFIGURE_ARGS
|
|
+= --prefix=${PREFIX}</literal>.</para>
|
|
|
|
<para>If you find yourself having to write a lot of new code to
|
|
try to do something, please go back and review
|
|
<filename>bsd.port.mk</filename> to see if it contains an
|
|
existing implementation of what you are trying to do. While
|
|
hard to read, there are a great many seemingly-hard problems
|
|
for which <filename>bsd.port.mk</filename> already provides a
|
|
shorthand solution.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-cc">
|
|
<title>Respect Both <makevar>CC</makevar> and
|
|
<makevar>CXX</makevar></title>
|
|
|
|
<para>The port must respect both <makevar>CC</makevar> and
|
|
<makevar>CXX</makevar> variables. What we mean by this is
|
|
that the port must not set the values of these variables
|
|
absolutely, overriding existing values; instead, it may
|
|
append whatever values it needs to the existing values. This
|
|
is so that build options that affect all ports can be set
|
|
globally.</para>
|
|
|
|
<para>If the port does not respect these variables,
|
|
please add <literal>NO_PACKAGE=ignores either cc or
|
|
cxx</literal> to the <filename>Makefile</filename>.</para>
|
|
|
|
<para>An example of a <filename>Makefile</filename> respecting
|
|
both <makevar>CC</makevar> and <makevar>CXX</makevar>
|
|
variables follows. Note the <makevar>?=</makevar>:</para>
|
|
|
|
<programlisting>CC?= gcc</programlisting>
|
|
|
|
<programlisting>CXX?= g++</programlisting>
|
|
|
|
<para>Here is an example which respects neither
|
|
<makevar>CC</makevar> nor <makevar>CXX</makevar>
|
|
variables:</para>
|
|
|
|
<programlisting>CC= gcc</programlisting>
|
|
|
|
<programlisting>CXX= g++</programlisting>
|
|
|
|
<para>Both <makevar>CC</makevar> and <makevar>CXX</makevar>
|
|
variables can be defined on FreeBSD systems in
|
|
<filename>/etc/make.conf</filename>. The first example
|
|
defines a value if it was not previously set in
|
|
<filename>/etc/make.conf</filename>, preserving any
|
|
system-wide definitions. The second example clobbers
|
|
anything previously defined.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-cflags">
|
|
<title>Respect <makevar>CFLAGS</makevar></title>
|
|
|
|
<para>The port must respect the <makevar>CFLAGS</makevar>
|
|
variable. What we mean by this is that the port must not
|
|
set the value of this variable absolutely, overriding the
|
|
existing value; instead, it may append whatever values it
|
|
needs to the existing value. This is so that build options
|
|
that affect all ports can be set globally.</para>
|
|
|
|
<para>If it does not, please add <literal>NO_PACKAGE=ignores
|
|
cflags</literal> to the
|
|
<filename>Makefile</filename>.</para>
|
|
|
|
<para>An example of a <filename>Makefile</filename> respecting
|
|
the <makevar>CFLAGS</makevar> variable follows. Note the
|
|
<makevar>+=</makevar>:</para>
|
|
|
|
<programlisting>CFLAGS+= -Wall -Werror</programlisting>
|
|
|
|
<para>Here is an example which does not respect the
|
|
<makevar>CFLAGS</makevar> variable:</para>
|
|
|
|
<programlisting>CFLAGS= -Wall -Werror</programlisting>
|
|
|
|
<para>The <makevar>CFLAGS</makevar> variable is defined on
|
|
FreeBSD systems in <filename>/etc/make.conf</filename>. The
|
|
first example appends additional flags to the
|
|
<makevar>CFLAGS</makevar> variable, preserving any system-wide
|
|
definitions. The second example clobbers anything previously
|
|
defined.</para>
|
|
|
|
<para>You should remove optimization flags from the third party
|
|
<filename>Makefile</filename>s. System
|
|
<makevar>CFLAGS</makevar> contains system-wide optimization
|
|
flags. An example from an unmodified
|
|
<filename>Makefile</filename>:</para>
|
|
|
|
<programlisting>CFLAGS= -O3 -funroll-loops -DHAVE_SOUND</programlisting>
|
|
|
|
<para>Using system optimization flags, the
|
|
<filename>Makefile</filename> would look similar to the
|
|
following example:</para>
|
|
|
|
<programlisting>CFLAGS+= -DHAVE_SOUND</programlisting>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-pthread">
|
|
<title>Threading Libraries</title>
|
|
|
|
<para>The threading library must be linked to the binaries using
|
|
a special linker flag <literal>-pthread</literal> on &os;. If
|
|
a port insists on linking <literal>-lpthread</literal> or
|
|
<literal>-lc_r</literal> directly, patch it to use
|
|
<makevar>PTHREAD_LIBS</makevar> variable provided by the ports
|
|
framework. This variable usually has the value of
|
|
<literal>-pthread</literal>, but on certain architectures and
|
|
&os; versions it can have different values, so do not just
|
|
hardcode <literal>-pthread</literal> into patches and always
|
|
use <makevar>PTHREAD_LIBS</makevar>.</para>
|
|
|
|
<note>
|
|
<para>If building the port errors out with
|
|
<literal>unrecognized option '-pthread'</literal> when
|
|
setting <makevar>PTHREAD_LIBS</makevar>, it may be desirable
|
|
to use <command>gcc</command> as linker by setting
|
|
<makevar>CONFIGURE_ENV</makevar> to
|
|
<literal>LD=${CC}</literal>. The
|
|
<literal>-pthread</literal> option is not supported by
|
|
<command>ld</command> directly.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-freedback">
|
|
<title>Feedback</title>
|
|
|
|
<para>Do send applicable changes/patches to the original
|
|
author/maintainer for inclusion in next release of the code.
|
|
This will only make your job that much easier for the next
|
|
release.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-readme">
|
|
<title><filename>README.html</filename></title>
|
|
|
|
<para>Do not include the <filename>README.html</filename> file.
|
|
This file is not part of the SVN collection but is generated
|
|
using the <command>make readme</command> command.</para>
|
|
|
|
<note>
|
|
<para>If <command>make readme</command> fails, make sure that
|
|
the default value of <makevar>ECHO_MSG</makevar> has not
|
|
been modified by the port.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-noinstall">
|
|
<title>Marking a Port Not Installable with
|
|
<makevar>BROKEN</makevar>, <makevar>FORBIDDEN</makevar>, or
|
|
<makevar>IGNORE</makevar></title>
|
|
|
|
<para>In certain cases users should be prevented from installing
|
|
a port. To tell a user that a port should not be installed,
|
|
there are several <command>make</command> variables that can
|
|
be used in a port's <filename>Makefile</filename>. The value
|
|
of the following <command>make</command> variables will be the
|
|
reason that is given back to users for why the port refuses to
|
|
install itself. Please use the correct
|
|
<command>make</command> variable as each make variable conveys
|
|
radically different meanings to both users, and to automated
|
|
systems that depend on the <filename>Makefile</filename>s,
|
|
such as <link linkend="build-cluster">the ports build
|
|
cluster</link>, <link linkend="freshports">FreshPorts</link>,
|
|
and <link linkend="portsmon">portsmon</link>.</para>
|
|
|
|
<sect2 id="dads-noinstall-variables">
|
|
<title>Variables</title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><makevar>BROKEN</makevar> is reserved for ports that
|
|
currently do not compile, install, or deinstall
|
|
correctly. It should be used for ports where the
|
|
problem is believed to be temporary.</para>
|
|
|
|
<para>If instructed, the build cluster will still attempt
|
|
to try to build them to see if the underlying problem
|
|
has been resolved. (However, in general, the cluster is
|
|
run without this.)</para>
|
|
|
|
<para>For instance, use <makevar>BROKEN</makevar> when a
|
|
port:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>does not compile</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>fails its configuration or installation
|
|
process</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>installs files outside of
|
|
<filename>${LOCALBASE}</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>does not remove all its files cleanly upon
|
|
deinstall (however, it may be acceptable, and
|
|
desirable, for the port to leave user-modified files
|
|
behind)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>FORBIDDEN</makevar> is used for ports that
|
|
contain a security vulnerability or induce grave
|
|
concern regarding the security of a FreeBSD system with
|
|
a given port installed (e.g., a reputably insecure program
|
|
or a program that provides easily exploitable services).
|
|
Ports should be marked as <makevar>FORBIDDEN</makevar>
|
|
as soon as a particular piece of software has a
|
|
vulnerability and there is no released upgrade. Ideally
|
|
ports should be upgraded as soon as possible when a
|
|
security vulnerability is discovered so as to reduce the
|
|
number of vulnerable FreeBSD hosts (we like being known
|
|
for being secure), however sometimes there is a
|
|
noticeable time gap between disclosure of a
|
|
vulnerability and an updated release of the vulnerable
|
|
software. Do not mark a port
|
|
<makevar>FORBIDDEN</makevar> for any reason other than
|
|
security.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><makevar>IGNORE</makevar> is reserved for ports that
|
|
should not be built for some other reason. It should be
|
|
used for ports where the problem is believed to be
|
|
structural. The build cluster will not, under any
|
|
circumstances, build ports marked as
|
|
<makevar>IGNORE</makevar>. For instance, use
|
|
<makevar>IGNORE</makevar> when a port:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>compiles but does not run properly</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>does not work on the installed version of
|
|
&os;</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>requires &os; kernel sources to build, but the
|
|
user does not have them installed</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>has a distfile which may not be automatically
|
|
fetched due to licensing restrictions</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>does not work with some other currently
|
|
installed port (for instance, the port depends on
|
|
<filename role="package">www/apache20</filename> but
|
|
<filename role="package">www/apache22</filename> is
|
|
installed)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>If a port would conflict with a currently
|
|
installed port (for example, if they install a file in
|
|
the same place that performs a different function),
|
|
<link linkend="conflicts">use
|
|
<makevar>CONFLICTS</makevar> instead</link>.
|
|
<makevar>CONFLICTS</makevar> will set
|
|
<makevar>IGNORE</makevar> by itself.</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If a port should be marked <makevar>IGNORE</makevar>
|
|
only on certain architectures, there are two other
|
|
convenience variables that will automatically set
|
|
<makevar>IGNORE</makevar> for you:
|
|
<makevar>ONLY_FOR_ARCHS</makevar> and
|
|
<makevar>NOT_FOR_ARCHS</makevar>. Examples:</para>
|
|
|
|
<programlisting>ONLY_FOR_ARCHS= i386 amd64</programlisting>
|
|
|
|
<programlisting>NOT_FOR_ARCHS= ia64 sparc64</programlisting>
|
|
|
|
<para>A custom <makevar>IGNORE</makevar> message can be
|
|
set using <makevar>ONLY_FOR_ARCHS_REASON</makevar> and
|
|
<makevar>NOT_FOR_ARCHS_REASON</makevar>. Per
|
|
architecture entries are possible with
|
|
<makevar>ONLY_FOR_ARCHS_REASON_<replaceable>ARCH</replaceable></makevar>
|
|
and
|
|
<makevar>NOT_FOR_ARCHS_REASON_<replaceable>ARCH</replaceable></makevar>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If a port fetches i386 binaries and installs them,
|
|
<makevar>IA32_BINARY_PORT</makevar> should be set. If
|
|
this variable is set, it will be checked whether the
|
|
<filename>/usr/lib32</filename> directory is available
|
|
for IA32 versions of libraries and whether the kernel
|
|
has IA32 compatibility compiled in. If one of these two
|
|
dependencies is not satisfied, <makevar>IGNORE</makevar>
|
|
will be set automatically.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2 id="dads-noinstall-notes">
|
|
<title>Implementation Notes</title>
|
|
|
|
<para>The strings should not be quoted.
|
|
Also, the wording of the string should be somewhat
|
|
different due to the way the information is shown to the
|
|
user. Examples:</para>
|
|
|
|
<programlisting>BROKEN= this port is unsupported on FreeBSD 5.x</programlisting>
|
|
|
|
<programlisting>IGNORE= is unsupported on FreeBSD 5.x</programlisting>
|
|
|
|
<para>resulting in the following output from
|
|
<command>make describe</command>:</para>
|
|
|
|
<programlisting>===> foobar-0.1 is marked as broken: this port is unsupported on FreeBSD 5.x.</programlisting>
|
|
|
|
<programlisting>===> foobar-0.1 is unsupported on FreeBSD 5.x.</programlisting>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-deprecated">
|
|
<title>Marking a Port for Removal with
|
|
<makevar>DEPRECATED</makevar> or
|
|
<makevar>EXPIRATION_DATE</makevar></title>
|
|
|
|
<para>Do remember that <makevar>BROKEN</makevar> and
|
|
<makevar>FORBIDDEN</makevar> are to be used as a temporary
|
|
resort if a port is not working. Permanently broken ports
|
|
should be removed from the tree entirely.</para>
|
|
|
|
<para>When it makes sense to do so, users can be warned about
|
|
a pending port removal with <makevar>DEPRECATED</makevar>
|
|
and <makevar>EXPIRATION_DATE</makevar>. The former is
|
|
simply a string stating why the port is scheduled for removal;
|
|
the latter is a string in ISO 8601 format (YYYY-MM-DD). Both
|
|
will be shown to the user.</para>
|
|
|
|
<para>It is possible to set <makevar>DEPRECATED</makevar>
|
|
without an <makevar>EXPIRATION_DATE</makevar> (for instance,
|
|
recommending a newer version of the port), but the converse
|
|
does not make any sense.</para>
|
|
|
|
<para>There is no set policy on how much notice to give.
|
|
Current practice seems to be one month for security-related
|
|
issues and two months for build issues. This also gives any
|
|
interested committers a little time to fix the
|
|
problems.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-dot-error">
|
|
<title>Avoid Use of the <literal>.error</literal>
|
|
Construct</title>
|
|
|
|
<para>The correct way for a <filename>Makefile</filename> to
|
|
signal that the port can not be installed due to some external
|
|
factor (for instance, the user has specified an illegal
|
|
combination of build options) is to set a non-blank value to
|
|
<makevar>IGNORE</makevar>. This value will be formatted and
|
|
shown to the user by <command>make install</command>.</para>
|
|
|
|
<para>It is a common mistake to use <literal>.error</literal>
|
|
for this purpose. The problem with this is that many
|
|
automated tools that work with the ports tree will fail in
|
|
this situation. The most common occurrence of this is seen
|
|
when trying to build <filename>/usr/ports/INDEX</filename>
|
|
(see <xref linkend="make-describe"/>). However, even more
|
|
trivial commands such as <command>make maintainer</command>
|
|
also fail in this scenario. This is not acceptable.</para>
|
|
|
|
<example id="dot-error-breaks-index">
|
|
<title>How to Avoid Using <literal>.error</literal></title>
|
|
|
|
<para>Assume that someone has the line</para>
|
|
|
|
<programlisting>USE_POINTYHAT=yes</programlisting>
|
|
|
|
<para>in <filename>make.conf</filename>. The first of the
|
|
next two <filename>Makefile</filename> snippets will cause
|
|
<command>make index</command> to fail, while the second one
|
|
will not:</para>
|
|
|
|
<programlisting>.if USE_POINTYHAT
|
|
.error "POINTYHAT is not supported"
|
|
.endif</programlisting>
|
|
|
|
<programlisting>.if USE_POINTYHAT
|
|
IGNORE= POINTYHAT is not supported
|
|
.endif</programlisting>
|
|
</example>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-sysctl">
|
|
<title>Usage of <filename>sysctl</filename></title>
|
|
|
|
<para>The usage of <filename>sysctl</filename> is discouraged
|
|
except in targets. This is because the evaluation of any
|
|
<literal>makevar</literal>s, such as used during
|
|
<command>make index</command>, then has to run the command,
|
|
further slowing down that process.</para>
|
|
|
|
<para>Usage of &man.sysctl.8; should always be done with the
|
|
<makevar>SYSCTL</makevar> variable, as it contains the fully
|
|
qualified path and can be overridden, if one has such a
|
|
special need.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-rerolling-distfiles">
|
|
<title>Rerolling Distfiles</title>
|
|
|
|
<para>Sometimes the authors of software change the content of
|
|
released distfiles without changing the file's name. You have
|
|
to verify that the changes are official and have been
|
|
performed by the author. It has happened in the past that the
|
|
distfile was silently altered on the download servers with the
|
|
intent to cause harm or compromise end user security.</para>
|
|
|
|
<para>Put the old distfile aside, download the new one, unpack
|
|
them and compare the content with &man.diff.1;. If you see
|
|
nothing suspicious, you can update
|
|
<filename>distinfo</filename>. Be sure to summarize the
|
|
differences in your PR or commit log, so that other people
|
|
know that you have taken care to ensure that nothing bad has
|
|
happened.</para>
|
|
|
|
<para>You might also want to contact the authors of the software
|
|
and confirm the changes with them.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="dads-avoiding-linuxisms">
|
|
<title>Avoiding Linuxisms</title>
|
|
|
|
<para>Do not use <filename>/proc</filename> if there are any
|
|
other ways of getting the information, e.g.
|
|
<function>setprogname(argv[0])</function> in
|
|
<function>main()</function> and then &man.getprogname.3; if
|
|
you want to <quote>know your name</quote>.</para>
|
|
|
|
<para>Do not rely on behaviour that is undocumented by
|
|
<acronym>POSIX</acronym>.</para>
|
|
|
|
<para>Do not record timestamps in the critical path of the
|
|
application if it also works without. Getting timestamps may
|
|
be slow, depending on the accuracy of timestamps in the
|
|
<acronym>OS</acronym>. If timestamps are really needed,
|
|
determine how precise they have to be and use an
|
|
<acronym>API</acronym> which is documented to just deliver the
|
|
needed precision.</para>
|
|
|
|
<para>A number of simple syscalls (for example
|
|
&man.gettimeofday.2;, &man.getpid.2;) are much faster on
|
|
&linux; than on any other operating system due to caching and
|
|
the vsyscall performance optimizations. Do not rely on them
|
|
being cheap in performance-critical applications. In general,
|
|
try hard to avoid syscalls if possible.</para>
|
|
|
|
<para>Do not rely on &linux;-specific socket behaviour. In
|
|
particular, default socket buffer sizes are different (call
|
|
&man.setsockopt.2; with <literal>SO_SNDBUF</literal> and
|
|
<literal>SO_RCVBUF</literal>, and while &linux;'s &man.send.2;
|
|
blocks when the socket buffer is full, &os;'s will fail and
|
|
set <literal>ENOBUFS</literal> in errno.</para>
|
|
|
|
<para>If relying on non-standard behaviour is required,
|
|
encapsulate it properly into a generic <acronym>API</acronym>,
|
|
do a check for the behaviour in the configure stage, and stop
|
|
if it is missing.</para>
|
|
|
|
<para>Check the <ulink
|
|
url="http://www.freebsd.org/cgi/man.cgi">man pages</ulink> to
|
|
see if the function used is a <acronym>POSIX</acronym>
|
|
interface (in the <quote>STANDARDS</quote> section of the man
|
|
page).</para>
|
|
|
|
<para>Do not assume that <filename>/bin/sh</filename> is
|
|
<application>bash</application>. Ensure that a command line
|
|
passed to &man.system.3; will work with a
|
|
<acronym>POSIX</acronym> compliant shell.</para>
|
|
|
|
<para>A list of common <application>bash</application>isms is
|
|
available <ulink
|
|
url="https://wiki.ubuntu.com/DashAsBinSh">here</ulink>.</para>
|
|
|
|
<para>Do not <literal>#include
|
|
<filename><stdint.h></filename></literal> if
|
|
<filename>inttypes.h</filename> is sufficient. This will
|
|
ensure that the software builds on older versions of
|
|
&os;.</para>
|
|
|
|
<para>Check that headers are included in the
|
|
<acronym>POSIX</acronym> or man page recommended way, e.g.
|
|
<filename>sys/types.h</filename> is often forgotten, which is
|
|
not as much of a problem for &linux; as it is for &os;.</para>
|
|
|
|
<para>Compile threaded applications with
|
|
<quote>-pthread</quote>, not <quote>-lpthread</quote> or
|
|
variations thereof.</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="dads-misc">
|
|
<title>Miscellanea</title>
|
|
|
|
<para>The files <filename>pkg-descr</filename> and
|
|
<filename>pkg-plist</filename> should each be double-checked.
|
|
If you are reviewing a port and feel they can be worded
|
|
better, do so.</para>
|
|
|
|
<para>Do not copy more copies of the GNU General Public License
|
|
into our system, please.</para>
|
|
|
|
<para>Please be careful to note any legal issues! Do not let us
|
|
illegally distribute software!</para>
|
|
</sect1>
|
|
|
|
</chapter>
|
|
|
|
<chapter id="porting-samplem">
|
|
<title>A Sample <filename>Makefile</filename></title>
|
|
|
|
<para>Here is a sample <filename>Makefile</filename> that you can
|
|
use to create a new port. Make sure you remove all the extra
|
|
comments (ones between brackets)!</para>
|
|
|
|
<para>It is recommended that you follow this format (ordering of
|
|
variables, empty lines between sections, etc.). This format is
|
|
designed so that the most important information is easy to
|
|
locate. We recommend that you use <link
|
|
linkend="porting-portlint">portlint</link> to check the
|
|
<filename>Makefile</filename>.</para>
|
|
|
|
<programlisting>[the header...just to make it easier for us to identify the ports.]
|
|
# New ports collection makefile for: xdvi
|
|
[the "version required" line is only needed when the PORTVERSION
|
|
variable is not specific enough to describe the port.]
|
|
# Date created: 26 May 1995
|
|
[this is the person who did the original port to FreeBSD, in particular, the
|
|
person who wrote the first version of this Makefile. Remember, this should
|
|
not be changed when upgrading the port later.]
|
|
# Whom: Satoshi Asami <asami@FreeBSD.org>
|
|
#
|
|
# $FreeBSD$
|
|
[ ^^^^^^^^^ This will be automatically replaced with RCS ID string by SVN
|
|
when it is committed to our repository. If upgrading a port, do not alter
|
|
this line back to "$FreeBSD$". SVN deals with it automatically.]
|
|
#
|
|
|
|
[section to describe the port itself and the master site - PORTNAME
|
|
and PORTVERSION are always first, followed by CATEGORIES,
|
|
and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
|
|
PKGNAMEPREFIX and PKGNAMESUFFIX, if needed, will be after that.
|
|
Then comes DISTNAME, EXTRACT_SUFX and/or DISTFILES, and then
|
|
EXTRACT_ONLY, as necessary.]
|
|
PORTNAME= xdvi
|
|
PORTVERSION= 18.2
|
|
CATEGORIES= print
|
|
[do not forget the trailing slash ("/")!
|
|
if you are not using MASTER_SITE_* macros]
|
|
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
|
|
MASTER_SITE_SUBDIR= applications
|
|
PKGNAMEPREFIX= ja-
|
|
DISTNAME= xdvi-pl18
|
|
[set this if the source is not in the standard ".tar.gz" form]
|
|
EXTRACT_SUFX= .tar.Z
|
|
|
|
[section for distributed patches -- can be empty]
|
|
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
|
|
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
|
|
|
|
[maintainer; *mandatory*! This is the person who is volunteering to
|
|
handle port updates, build breakages, and to whom a users can direct
|
|
questions and bug reports. To keep the quality of the Ports Collection
|
|
as high as possible, we no longer accept new ports that are assigned to
|
|
"ports@FreeBSD.org".]
|
|
MAINTAINER= asami@FreeBSD.org
|
|
COMMENT= A DVI Previewer for the X Window System
|
|
|
|
[dependencies -- can be empty]
|
|
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
|
|
LIB_DEPENDS= Xpm:${PORTSDIR}/graphics/xpm
|
|
|
|
[this section is for other standard bsd.port.mk variables that do not
|
|
belong to any of the above]
|
|
[If it asks questions during configure, build, install...]
|
|
IS_INTERACTIVE= yes
|
|
[If it extracts to a directory other than ${DISTNAME}...]
|
|
WRKSRC= ${WRKDIR}/xdvi-new
|
|
[If the distributed patches were not made relative to ${WRKSRC}, you
|
|
may need to tweak this]
|
|
PATCH_DIST_STRIP= -p1
|
|
[If it requires a "configure" script generated by GNU autoconf to be run]
|
|
GNU_CONFIGURE= yes
|
|
[If it requires GNU make, not /usr/bin/make, to build...]
|
|
USE_GMAKE= yes
|
|
[If it is an X application and requires "xmkmf -a" to be run...]
|
|
USE_IMAKE= yes
|
|
[et cetera.]
|
|
|
|
[non-standard variables to be used in the rules below]
|
|
MY_FAVORITE_RESPONSE= "yeah, right"
|
|
|
|
[then the special rules, in the order they are called]
|
|
pre-fetch:
|
|
i go fetch something, yeah
|
|
|
|
post-patch:
|
|
i need to do something after patch, great
|
|
|
|
pre-install:
|
|
and then some more stuff before installing, wow
|
|
|
|
[and then the epilogue]
|
|
.include <bsd.port.mk></programlisting>
|
|
</chapter>
|
|
|
|
<chapter id="keeping-up">
|
|
<title>Keeping Up</title>
|
|
|
|
<para>The &os; Ports Collection is constantly changing. Here is
|
|
some information on how to keep up.</para>
|
|
|
|
<sect1 id="freshports">
|
|
<title>FreshPorts</title>
|
|
|
|
<para>One of the easiest ways to learn about updates that have
|
|
already been committed is by subscribing to <ulink
|
|
url="http://www.FreshPorts.org/">FreshPorts</ulink>. You
|
|
can select multiple ports to monitor. Maintainers are
|
|
strongly encouraged to subscribe, because they will receive
|
|
notification of not only their own changes, but also any
|
|
changes that any other &os; committer has made. (These are
|
|
often necessary to keep up with changes in the underlying
|
|
ports framework—although it would be most polite to
|
|
receive an advance heads-up from those committing such
|
|
changes, sometimes this is overlooked or just simply
|
|
impractical. Also, in some cases, the changes are very minor
|
|
in nature. We expect everyone to use their best judgement in
|
|
these cases.)</para>
|
|
|
|
<para>If you wish to use FreshPorts, all you need is an account.
|
|
If your registered email address is
|
|
<literal>@FreeBSD.org</literal>, you will see the opt-in link
|
|
on the right hand side of the webpages. For those of you who
|
|
already have a FreshPorts account, but are not using your
|
|
<literal>@FreeBSD.org</literal> email address, just change
|
|
your email to <literal>@FreeBSD.org</literal>, subscribe, then
|
|
change it back again.</para>
|
|
|
|
<para>FreshPorts also has a sanity test feature which
|
|
automatically tests each commit to the FreeBSD ports tree. If
|
|
subscribed to this service, you will be notified of any errors
|
|
which FreshPorts detects during sanity testing of your
|
|
commits.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="svnweb">
|
|
<title>The Web Interface to the Source Repository</title>
|
|
|
|
<para>It is possible to browse the files in the source
|
|
repository by using a web interface. Changes that affect the
|
|
entire port system are now documented in the <ulink
|
|
url="http://svnweb.FreeBSD.org/ports/head/CHANGES">CHANGES</ulink>
|
|
file. Changes that affect individual ports
|
|
are now documented in the <ulink
|
|
url="http://svnweb.FreeBSD.org/ports/head/UPDATING">UPDATING</ulink>
|
|
file. However, the definitive answer to
|
|
any question is undoubtedly to read the source code of <ulink
|
|
url="http://svnweb.FreeBSD.org/ports/head/Mk/bsd.port.mk">bsd.port.mk</ulink>,
|
|
and associated files.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="ports-mailling-list">
|
|
<title>The &os; Ports Mailing List</title>
|
|
|
|
<para>If you maintain ports, you should consider following the
|
|
&a.ports;. Important changes to the way ports work will be
|
|
announced there, and then committed to
|
|
<filename>CHANGES</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="build-cluster">
|
|
<title>The &os; Port Building Cluster on
|
|
<hostid role="hostname">pointyhat.FreeBSD.org</hostid></title>
|
|
|
|
<para>One of the least-publicized strengths of &os; is that
|
|
an entire cluster of machines is dedicated to continually
|
|
building the Ports Collection, for each of the major OS
|
|
releases and for each Tier-1 architecture. You can find
|
|
the results of these builds at <ulink
|
|
url="http://pointyhat.FreeBSD.org/">package building logs
|
|
and errors</ulink>.</para>
|
|
|
|
<para>Individual ports are built unless they are specifically
|
|
marked with <makevar>IGNORE</makevar>. Ports that are
|
|
marked with <makevar>BROKEN</makevar> will still be attempted,
|
|
to see if the underlying problem has been resolved. (This
|
|
is done by passing <makevar>TRYBROKEN</makevar> to the
|
|
port's <filename>Makefile</filename>.)</para>
|
|
</sect1>
|
|
|
|
<sect1 id="distfile-survey">
|
|
<title>Portscout: the &os; Ports Distfile Scanner</title>
|
|
|
|
<para>The build cluster is dedicated to building the latest
|
|
release of each port with distfiles that have already been
|
|
fetched. However, as the Internet continually changes,
|
|
distfiles can quickly go missing. <ulink
|
|
url="http://portscout.org">Portscout</ulink>, the &os;
|
|
Ports distfile scanner, attempts to query every download site
|
|
for every port to find out if each distfile is still
|
|
available. <application>Portscout</application> can generate
|
|
<acronym>HTML</acronym> reports and send emails about newly
|
|
available ports to those who request them. Unless not
|
|
otherwise subscribed, maintainers are asked to check
|
|
periodically for changes, either by hand or using the
|
|
<acronym>RSS</acronym> feed.</para>
|
|
|
|
<para><application>Portscout</application>'s first page gives
|
|
the email address of the port maintainer, the number of ports
|
|
the maintainer is responsible for, the number of those ports
|
|
with new distfiles, and the percentage of those ports that are
|
|
out-of-date. The search function allows for searching by
|
|
email address for a specific maintainer, and for selecting
|
|
whether or not only out-of-date ports should be shown.</para>
|
|
|
|
<para>Upon clicking on a maintainer's email address,
|
|
a list of all of their ports is displayed, along with port
|
|
category, current version number, whether or not there is a
|
|
new version, when the port was last updated, and finally when
|
|
it was last checked. A search function on this page allows
|
|
the user to search for a specific port.</para>
|
|
|
|
<para>Clicking on a port name in the list displays the
|
|
<ulink url="http://freshports.org">FreshPorts</ulink> port
|
|
information.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="portsmon">
|
|
<title>The &os; Ports Monitoring System</title>
|
|
|
|
<para>Another handy resource is the <ulink
|
|
url="http://portsmon.FreeBSD.org"> FreeBSD Ports Monitoring
|
|
System</ulink> (also known as <literal>portsmon</literal>).
|
|
This system comprises a database that processes information
|
|
from several sources and allows it to be browsed via a web
|
|
interface. Currently, the ports Problem Reports (PRs), the
|
|
error logs from the build cluster, and individual files from
|
|
the ports collection are used. In the future, this will be
|
|
expanded to include the distfile survey, as well as other
|
|
sources.</para>
|
|
|
|
<para>To get started, you can view all information about a
|
|
particular port by using the <ulink
|
|
url="http://portsmon.FreeBSD.org/portoverview.py">
|
|
Overview of One Port</ulink>.</para>
|
|
|
|
<para>As of this writing, this is the only resource available
|
|
that maps GNATS PR entries to portnames. (PR submitters do
|
|
not always include the portname in their Synopsis, although we
|
|
would prefer that they did.) So, <literal>portsmon</literal>
|
|
is a good place to start if you want to find out whether an
|
|
existing port has any PRs filed against it and/or any build
|
|
errors; or, to find out if a new port that you may be thinking
|
|
about creating has already been submitted.</para>
|
|
</sect1>
|
|
</chapter>
|
|
</book>
|