<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 24. Using Autoconf</title><meta name="generator" content="DocBook XSL Stylesheets V1.71.1"><link rel="start" href="index.html" title="A-A-P Recipe Executive"><link rel="up" href="user.html" title="Part II. User Manual"><link rel="prev" href="user-configure.html" title="Chapter 23. Automatic Configuration"><link rel="next" href="user-package.html" title="Chapter 25. Automatic Package Install"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><table width="100%" id="navtable"><tbody><tr><td align="left" class="left" width="33%"><b><a href="http://www.a-a-p.org">A-A-P home page</a></b></td><td align="center" class="center" width="34%"><b><a href="index.html">A-A-P Recipe Executive</a></b></td><td align="right" class="right" width="33%"></td></tr><tr><td align="left" class="left"><a accesskey="p" href="user-configure.html">Prev</a></td><td align="center" class="center">User Manual</td><td align="right" class="right"><a accesskey="n" href="user-package.html">Next</a></td></tr></tbody></table><hr><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="user-autoconf"></a>Chapter 24. Using Autoconf</h2></div></div></div><p>
The autoconf system is often used to configure C programs to be able to
compile them on any Unix system. This section explains how to use autoconf
with <span class="application">Aap</span> in a nice way. An alternative is to use the
<a href="ref-commands.html#cmd-conf">:conf</a> command of <span class="application">Aap</span>. It is much easier to
use and also works on non-Unix systems. See <a href="user-configure.html" title="Chapter 23. Automatic Configuration">Chapter 23, <i>Automatic Configuration</i></a>.
</p><h2><a name="id2656413"></a>Running The Configure Script</h2><p>
A recipe that uses the configure script that autoconf generates can start like
this:
</p><pre class="programlisting">
$BDIR/config.h $BDIR/config.aap :
configure config.arg config.h.in config.aap.in
:sys ./configure `file2string("config.arg")`
:move {force} config.h config.aap config.log
config.cache config.status $BDIR
config.arg:
:touch {exist} config.arg
:update $BDIR/config.aap
:include $BDIR/config.aap
</pre><p>
What happens here is that the "config.aap" target is updated before any of the
building is done. This is required, because running the configure script
will generate or update the "config.aap" file that influences how the building
is done.
</p><h2><a name="id2656428"></a>Remembering Configure Arguments</h2><p>
The arguments for configure are stored in the "config.arg" file. This
makes it easy to run configure again with the same arguments. The file is
read with the <a href="ref-python.html#python-file2string">file2string()</a>
function. There should be a "config.txt" file that explains all the possible
configure arguments, with examples that can be copied into "config.arg".
Example:
</p><pre class="programlisting">
# Select the library to be used for terminal access. When omitted a
# series of libraries will be tried. Useful values:
--with-tlib=curses
--with-tlib=termcap
--with-tlib=termlib
</pre><p>
The user can now copy one of the example lines to his "config.arg" file.
Example:
</p><pre class="programlisting">
# select specific terminal library
--with-tlib=termcap
</pre><p>
Comment lines can be used, they must start with a "#". Note: a comment after
an argument doesn't work, it will be seen as an argument.
</p><p>
When updating to a new version of the program, the same "config.arg" file
can still be used. A "diff" between the old and the new "config.txt" will
show what configure arguments have changed.
</p><h2><a name="id2656460"></a>Variants And Configure</h2><p>
"config.aap" and "config.h" are put in $BDIR, because they depend on the
current system. They might also depend on the variant to be built. In that
case the
<a href="ref-commands.html#cmd-variant">:variant</a> statement must be before the use
of $BDIR. However, if the variant is selected by running configure, the
variant must come later.
"config.aap" and "config.h" are then updated when selecting another variant.
</p><p>
For the program to find "config.h" in $BDIR you must add an option to the C
compiler. And you have to notify the compiler that the file exists, so that
it will be included:
</p><pre class="programlisting">
INCLUDE += -I$BDIR
DEFINE += -DHAVE_CONFIG_H
</pre><p>
The "config.cache", "config.log" and "config.status" files are also moved to
$BDIR. This means they are not available when running "./configure" again.,
This may be a bit slower, since the cache isn't used, but it is much more
reliable. And you can view the log of each variant that was build.
</p><h2><a name="id2656485"></a>Running Autoconf</h2><p>
For a developer there also needs to be a method to generate the configure
script from configure.in. This needs to be done even before configure is run.
Prepending this to the example above should work:
</p><pre class="programlisting">
configure {signfile = mysign} : configure.in
:sys autoconf
</pre><p>
Normally the "configure" script is distributed with the program, so that a
user does not need to install and run autoconf.
The "{signfile = mysign}" attribute on the target is used to avoid running
autoconf when the user builds the program and the "configure" and
"configure.in" files are still as they were distributed. The signatures in
the "mysign" file, which you must include in the distribution, will match
and <span class="application">Aap</span> knows that "configure" is up-to-date.
If using the "mysign" file was omitted,
there would be no signature for the "configure" target and <span class="application">Aap</span> would
decide to run autoconf.
When you change "configure.in" its signature will be different from what is
stored in "mysign" and autoconf will be run.
</p><h2><a name="id2656510"></a>Using A Distributed Configure Script</h2><p>
If you are porting an application that already has a configure script you
can filter it to make it work with <span class="application">Aap</span>. This means you can use the
unmodified configure.in.
</p><pre class="programlisting">
configure_aap : configure
:cat configure
| :eval re.sub("Makefile", "config.aap", stdin)
>! configure_aap
:chmod 755 configure_aap
</pre><p>
Now you need to execute "configure_aap" instead of "configure" in the first
example above.
</p><h2><a name="id2656942"></a>Skipping Configuration</h2><p>
Running configure can take quite a bit of time. And when you are not going
to build anything that can be annoying. For example, "aap comment" doesn't
require configure to run.
</p><p>
Also, configure doesn't work on a non-Unix system. When you have taken care
in your code to handle this you can simply skip configure. This line above
all the configure code should take care of this:
</p><pre class="programlisting">
@if osname() == "posix" and has_build_target():
</pre><p>
The <a href="ref-python.html#python-has-build-target">has_build_target()</a>
function checks for a target that will do some kind of building, which means
configure must be run.
</p><h2><a name="id2656967"></a>A Complete Example</h2><p>
Using all the parts mentioned above together we have a fairly complete
method to handle running autoconf and configure. This code is used in the
recipe that builds the Exuberant Ctags program.
</p><pre class="programlisting">
#
# On Unix we run configure to generate config.h and config.aap.
# This is skipped if there is no building to be done (e.g., for "clean").
#
@if osname() == "posix" and has_build_target():
# "config.h" and "config.aap" are generated in $BDIR, because the are
# different for each system.
# Tell the compiler to find config.h in $BDIR.
INCLUDE += -I$BDIR
DEFINE += -DHAVE_CONFIG_H
# Run autoconf when needed, but avoid doing this always, not everybody has
# autoconf installed. Include "mysign" in the distribution, it stores the
# signature of the distributed configure script.
configure {signfile = mysign} : configure.in
@if not program_path("autoconf"):
:print Can't find autoconf, using existing configure script.
@else:
:sys autoconf
# Filter the configure script created by autoconf to generate config.aap
# instead of Makefile. This means we can use the unmodified configure.in
# distributed with ctags.
configure_aap : configure
:cat configure
| :eval re.sub("Makefile", "config.aap", stdin)
>! configure_aap
:chmod 755 configure_aap
# Dependency to create config.aap by running the configure script.
# The "config.arg" file is used for configure arguments.
:attr config {virtual} {comment = Do configuration only}
config $BDIR/config.h $BDIR/config.aap :
configure_aap config.arg config.h.in config.aap.in
:sys ./configure_aap `file2string("config.arg")`
# Move the results into $BDIR. This also means the cache isn't used
# the next time, it is unreliable.
:move {force} config.h config.aap config.log config.cache
config.status $BDIR
# Create an empty config.arg when it's missing.
config.arg:
:touch {exist} config.arg
# Update config.aap before including it. Forcefully when the "reconfig"
# target is used.
@if "reconfig" in var2list(_no.TARGETARG):
:del {force} config.cache config.status
:update {force} $BDIR/config.aap
@else:
:update $BDIR/config.aap
:include $BDIR/config.aap
</pre></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="user-configure.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="user.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="user-package.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 23. Automatic Configuration </td><td width="20%" align="center"><a accesskey="h" href="index.html">
Contents</a></td><td width="40%" align="right" valign="top"> Chapter 25. Automatic Package Install</td></tr></table></div></body></html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
a6d417e36f6bb1154f4c003e6717e298
>
files
>
147
