autobook_62.html

Autoconf使用手册

allow the rest of the project to be written in the knowledge that any
functions required by the project but missing from the installers system
libraries will be available nonetheless.  GNU <TT>`libiberty'</TT>
comes to the rescue again -- it already has an implementation of
<TT>`strerror.c'</TT> that I was able to use with a little modification.
</P><P>

Being able to supply a simple implementation of <CODE>strerror</CODE>, as the
<TT>`strerror.c'</TT> file from <TT>`libiberty'</TT> does, relies on there being
a well defined <CODE>sys_errlist</CODE> variable.  It is a fair bet that if
the target host has no <CODE>strerror</CODE> implementation, however, that the
system <CODE>sys_errlist</CODE> will be broken or missing.  I need to write a
configure macro to check whether the system defines <CODE>sys_errlist</CODE>,
and tailor the code in <TT>`strerror.c'</TT> to use this knowledge.
</P><P>

To avoid clutter in the top-level directory, I am a great believer in
keeping as many of the configuration files as possible in their own
sub-directory.   First of all, I will create a new directory called
<SAMP>`config'</SAMP> inside the top-level directory, and put
<TT>`sys_errlist.m4'</TT> inside it:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>
</pre></td></tr></table></P><P>

I must then add a call to this new macro in the <TT>`configure.in'</TT> file
 being careful to put it in the right place --
somewhere between <EM>typedefs and structures</EM> and <EM>library
functions</EM> according to the comments in <TT>`configure.scan'</TT>:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>SIC_VAR_SYS_ERRLIST
</pre></td></tr></table></P><P>

GNU Autotools can also be set to store most of their files in a
subdirectory, by calling the <CODE>AC_CONFIG_AUX_DIR</CODE> macro near the top
of <TT>`configure.in'</TT>, preferably right after <CODE>AC_INIT</CODE>:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>AC_INIT(sic/eval.c)
AC_CONFIG_AUX_DIR(config)
AM_CONFIG_HEADER(config.h)
...
</pre></td></tr></table></P><P>

Having made this change, many of the files added by running
<CODE>autoconf</CODE> and <CODE>automake --add-missing</CODE> will be put in
the <EM>aux_dir</EM>.
</P><P>

The source tree now looks like this:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>sic/
  +-- configure.scan
  +-- config/
  |     +-- sys_errlist.m4
  +-- replace/
  |     +-- strerror.c
  +-- sic/
        +-- builtin.c
        +-- builtin.h
        +-- common.h
        +-- error.c
        +-- error.h
        +-- eval.c
        +-- eval.h
        +-- list.c
        +-- list.h
        +-- sic.c
        +-- sic.h
        +-- syntax.c
        +-- syntax.h
        +-- xmalloc.c
        +-- xstrdup.c
        +-- xstrerror.c
</pre></td></tr></table></P><P>

In order to correctly utilise the fallback implementation,
<CODE>AC_CHECK_FUNCS(strerror)</CODE> needs to be removed and <CODE>strerror</CODE>
added to <CODE>AC_REPLACE_FUNCS</CODE>:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre># Checks for library functions.
AC_REPLACE_FUNCS(strerror)
</pre></td></tr></table></P><P>

This will be clearer if you look at the <TT>`Makefile.am'</TT> for the
<TT>`replace'</TT> subdirectory:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>
</pre></td></tr></table></P><P>

The code tells <CODE>automake</CODE> that I want to build a library for use
within the build tree (i.e. not installed -- <SAMP>`noinst'</SAMP>), and that
has no source files by default.  The clever part here is that when
someone comes to install Sic, they will run <CODE>configure</CODE> which
will test for <CODE>strerror</CODE>, and add <TT>`strerror.o'</TT> to
<CODE>LIBOBJS</CODE> if the target host environment is missing its own
implementation.  Now, when <TT>`configure'</TT> creates
<TT>`replace/Makefile'</TT> (as I asked it to with <CODE>AC_OUTPUT</CODE>),
<SAMP>`@LIBOBJS@'</SAMP> is replaced by the list of objects required on the
installer's machine.
</P><P>

Having done all this at configure time, when my user runs
<CODE>make</CODE>, the files required to replace functions missing
from their target machine will be added to <TT>`libreplace.a'</TT>.
</P><P>

Unfortunately this is not quite enough to start building the project.
First I need to add a top-level <TT>`Makefile.am'</TT> from which to
ultimately create a top-level <TT>`Makefile'</TT> that will descend into
the various subdirectories of the project:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>## Makefile.am -- Process this file with automake to produce Makefile.in

SUBDIRS = replace sic
</pre></td></tr></table></P><P>

And <TT>`configure.in'</TT> must be told where it can find instances of
<CODE>Makefile.in</CODE>:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>AC_OUTPUT(Makefile replace/Makefile sic/Makefile)
</pre></td></tr></table></P><P>

I have written a <CODE>bootstrap</CODE> script for Sic, for details see
<A HREF="autobook_43.html#SEC43">8. Bootstrapping</A>:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>
</pre></td></tr></table></P><P>

The <SAMP>`--foreign'</SAMP> option to <CODE>automake</CODE> tells it to relax
the GNU standards for various files that should be present in a
GNU distribution.  Using this option saves me from having to create
empty files as we did in <A HREF="autobook_23.html#SEC23">5. A Minimal GNU Autotools Project</A>.
</P><P>

Right.  Let's build the library!  First, I'll run <CODE>bootstrap</CODE>:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>$ ./bootstrap
+ aclocal -I config
+ autoheader
+ automake --foreign --add-missing --copy
automake: configure.in: installing config/install-sh
automake: configure.in: installing config/mkinstalldirs
automake: configure.in: installing config/missing
+ autoconf
</pre></td></tr></table></P><P>

The project is now in the same state that an end-user would see, having
unpacked a distribution tarball.  What follows is what an end user might
expect to see when building from that tarball:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>$ ./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for unistd.h... yes
checking for errno.h... yes
checking for string.h... yes
checking for working const... yes
checking for size_t... yes
checking for strerror... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating replace/Makefile
creating sic/Makefile
creating config.h
</pre></td></tr></table></P><P>

Compare this output with the contents of <TT>`configure.in'</TT>, and notice
how each macro is ultimately responsible for one or more consecutive
tests (via the Bourne shell code generated in <TT>`configure'</TT>).  Now
that the <TT>`Makefile'</TT>s have been successfully created, it is safe to
call <CODE>make</CODE> to perform the actual compilation:
</P><P>

<TABLE width=100%><tr><td>&nbsp;</td><td class=example bgcolor=#6688aa><br><pre>$ make
make  all-recursive
make[1]: Entering directory `/tmp/sic'
Making all in replace
make[2]: Entering directory `/tmp/sic/replace'
rm -f libreplace.a
ar cru libreplace.a
ranlib libreplace.a
make[2]: Leaving directory `/tmp/sic/replace'
Making all in sic
make[2]: Entering directory `/tmp/sic/sic'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c builtin.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c error.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c eval.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c list.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c sic.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c syntax.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c xmalloc.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c xstrdup.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -O2 -c xstrerror.c
rm -f libsic.a
ar cru libsic.a builtin.o error.o eval.o list.o sic.o syntax.o xmalloc.o
xstrdup.o xstrerror.o
ranlib libsic.a
make[2]: Leaving directory `/tmp/sic/sic'
make[1]: Leaving directory `/tmp/sic'
</pre></td></tr></table></P><P>

On this machine, as you can see from the output of <CODE>configure</CODE>
above, I have no need of the fallback implementation of <CODE>strerror</CODE>,
so <TT>`libreplace.a'</TT> is empty.  On another machine this might not be
the case.  In any event, I now have a compiled <TT>`libsic.a'</TT> -- so
far, so good.
</P><P>

<A NAME="A Sample Shell Application"></A>
</TR></TABLE>
<BR>  
<FONT SIZE="-1">
This document was generated
by <I>Gary V. Vaughan</I> on <I>September, 12  2004</I>
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
"><I>texi2html</I></A>

</BODY>
</HTML>