USE_AUTOTOOLS was retired.

Sponsored by:	Absolight
This commit is contained in:
Mathieu Arnold 2018-03-20 11:16:04 +00:00
parent d2e08eb7a3
commit 0dc27bbf87
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=51510
2 changed files with 4 additions and 130 deletions

View file

@ -394,7 +394,7 @@
<command>configure</command>, do not take the diffs of
<command>configure</command> (it often grows to a few thousand
lines!). Instead, define
<literal>USE_AUTOTOOLS=autoconf:261</literal> and take the
<literal>USES=autoreconf</literal> and take the
diffs of <filename>configure.in</filename>.</para>
</sect2>

View file

@ -827,135 +827,9 @@ CMAKE_OFF= VAR3</programlisting>
<sect1 xml:id="using-autotools">
<title>Using GNU Autotools</title>
<sect2 xml: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>[:env] ...</programlisting>
<para>At the time of writing, <replaceable>tool</replaceable>
can be one of <literal>autoconf</literal>,
<literal>autoheader</literal>, <literal>automake</literal>,
<literal>aclocal</literal>, <literal>libtoolize</literal>.
It can also be one the older
legacy of <literal>autoconf213</literal>,
<literal>autoheader213</literal>,
<literal>automake14</literal>,
<literal>aclocal14</literal>.</para>
<para><replaceable>env</replaceable> is used to specify that the
environmental variables are needed. It also adds a build
dependency on the tool. The relevant tool is
<emphasis>not</emphasis> ran as part of the
<buildtarget>run-autotools</buildtarget> target.</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>
</sect2>
<sect2 xml:id="using-libtool">
<title><command>libtool</command> and
<command>libtoolize</command></title>
<para>Ports shipping with their own copy of libtool (search for
a file named ltmain.sh) need to have
<literal>USES=libtool</literal>. If a port has
<literal>USE_AUTOTOOLS=libtoolize</literal> it probably also
needs <literal>USES=libtool</literal>. See the <link
linkend="uses-libtool">USES=libtool</link> section in <xref
linkend="uses"/> for more details.</para>
</sect2>
<sect2 xml:id="using-libltdl">
<title><filename>libltdl.so</filename></title>
<para>Some ports make use of the <filename>libltdl.so</filename>
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. If the port needs
<filename>libltdl.so</filename>, add a dependency on
it:</para>
<programlisting>LIB_DEPENDS= libltdl.so:devel/libltdl</programlisting>
</sect2>
<sect2 xml: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
<filename>configure.ac</filename>. Use these
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[:env]</programlisting>
<para>and</para>
<programlisting>USE_AUTOTOOLS= autoheader</programlisting>
<para>which also implies the use of
<literal>autoconf</literal>.</para>
<para>The additional optional variables
<varname>AUTOCONF_ARGS</varname> and
<varname>AUTOHEADER_ARGS</varname> can be overridden by the
port <filename>Makefile</filename> if specifically
requested. Most ports are unlikely to need this. See
<filename>bsd.autotools.mk</filename> for further
details.</para>
</sect2>
<sect2 xml:id="using-automake">
<title><command>automake</command> and
<command>aclocal</command></title>
<para>Some packages only contain
<filename>Makefile.am</filename>. These have to be
converted into <filename>Makefile.in</filename> 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
an included <filename>aclocal.m4</filename>, 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>env</replaceable>]</programlisting>
<para>and</para>
<programlisting>USE_AUTOTOOLS= aclocal</programlisting>
<para>As with <command>autoconf</command> and
<command>autoheader</command>, both
<command>automake</command> and <command>aclocal</command>
have optional argument variables,
<varname>AUTOMAKE_ARGS</varname> and
<varname>ACLOCAL_ARGS</varname> respectively, which may be
overridden by the port <filename>Makefile</filename> if
required.</para>
</sect2>
<para>If a port needs any of the GNU Autotools software, add
<literal>USES=autoreconf</literal>. See <xref
linkend="uses-autoreconf"/> for more information.</para>
</sect1>
<sect1 xml:id="using-gettext">