creating-configuration.html

来自「linux下gnome编程」· HTML 代码 · 共 947 行 · 第 1/3 页

          these #define statements must either set the value to 0 or
          undefine it completely with #undef. autoconf uses the
          config.h.in file as a checklist for the various tests it
          runs. Each time it hits an AC_DEFINE macro, it searches the
          config.h.in file for a matching #define statement,
          uncomments it, and sets the value to 1.
        </P
><P
>          As a final step, autoconf puts the value -DHAVE_CONFIG_H
          into the DEFS variable. You'll still want to pass the value
          of DEFS to the compiler in your makefile (as @DEFS@ in
          Makefile.in), and then check for the HAVE_CONFIG_H macro in
          your source code. At the top of your source files you can do
          something like this:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>#ifdef HAVE_CONFIG_H
#include &#60;config.h&#62;
#endif
        </PRE
></TD
></TR
></TABLE
><P
>      As we'll see in Section 3.3, automake helps make this process
      even easier.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN361"
>Checking for Tools</A
></H2
><P
>          The autoconf package comes bundled with an exhaustive set of
          macros for probing target systems. Autoconf makes use of m4,
          a commonly available macro-processing program. As part of
          its own distribution, autoconf supplies numerous text files
          (all of which end in ".m4"), full of various m4 macros. The
          m4 macro language looks a little odd at first, but it can be
          very powerful when used correctly.
        </P
><P
>          As we've seen, autoconf expands these macros into shell
          commands in the configure script. Many people use m4 to
          create text files and perform a wide variety of other
          tasks. For example, GTK--, a C++ wrapper around GTK+, uses
          m4 to automate the creation of a great deal of repetitive
          source code. The UNIX e-mail transport utility sendmail uses
          m4 to generate its complex configuration files from an
          easy-to-read template. m4 is a generic tool with many uses.
        </P
><P
>          You can tap into this power by adding the m4 macros
          distributed with autoconf to your configure.in file. The
          configure.in file is in fact a mixture of m4 macros and
          inline shell script code. In addition to the initialization
          and variable-passing macros we saw in the previous
          section, autoconf comes with a broad selection of macros for
          probing standard UNIX tools. They typically don't require
          parameters. You just add each macro on its own line, without
          parentheses. If one of the prepackaged macros doesn't do
          what you want, you can write your own custom macro. Here are
          some common tool macros, exactly as they would appear in a
          configure.in file:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_PROG_CC
AC_PROG_CXX
AC_PROG_INSTALL
AC_PROG_YACC
AC_PROG_LN_S
AM_PROG_LIBTOOL
        </PRE
></TD
></TR
></TABLE
><P
>          Each one checks for the existence of a tool or program,
          first by seeing if it is explicitly named by the user in an
          environment variable, and if not, by searching the hard
          drive for it (i.e., the hard way). For example, AC_PROG_CC
          first checks to see if the CC environment variable is set on
          the end user's system. If it is, the configure script adds
          the contents of CC to the master list of variable
          substitutions. You can then reference @CC@ in your
          Makefile.in files, just like the other AC_SUBST
          variables. If the user hasn't explicitly set the environment
          variable CC, AC_PROG_CC will search the directories in the
          PATH environment variable for the gcc or cc executables. If
          it finds something, it will call AC_SUBST on that value
          instead. This makes it very easy for the user to override
          the default compiler before configuring a software package
          that has been processed by autoconf. If the configure
          script fails to find any trace of a compiler, it aborts
          the configuration process with an error message.
        </P
><P
>          The other AC_PROG_* macros work similarly. See the autoconf
          documentation for an explanation of each one. If you're
          feeling adventurous, you can explore autoconf's m4 files to
          find out what's really going on. You can find these files in
          the autoconf install directory, usually something like
          /usr/share/autoconf or /usr/lib/autoconf, depending on your
          distribution of UNIX or Linux. You may also want to
          consult the m4 documentation. If you plan on someday writing
          your own macros, this will be time well spent.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN369"
>Checking for Header Files</A
></H2
><P
>          A frequent problem with porting software is keeping track of
          header files. Different systems have headers in different
          places. If your software depends on other libraries, it
          should attempt to verify that those libraries and their
          accompanying header files are installed before continuing
          with the compilation of your package. For example, if you're
          compiling a GNOME application, you'll want to make sure the
          header files for the gnome-libs package are available.
        </P
><P
>          AC_CHECK_HEADER allows you to check for specific header
          files. You supply the name of the header file, plus an
          optional command if the header is found and another optional
          command if the header is not found.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
> AC_CHECK_HEADER (HEADER-FILE, [ACTION-IF-FOUND [,
          ACTION-IF-NOT-FOUND]])
        </PRE
></TD
></TR
></TABLE
><P
>          Here's an example that aborts the configure process if the
          header file grump.h isn't found. The autoconf system uses
          the square brackets-[ and ]- as the default quote characters
          for its m4 macros, rather than the double quotation mark
          ("), to make it easier to include double quotation marks in
          your macros. The AC_MSG_ERROR macro that follows prints
          out a message and then aborts the configure process. If you
          just want to print out a nonfatal warning or status message
          and then keep going, you can use the AC_MSG_RESULT macro
          instead.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_HEADER(grump.h, , [AC_MSG_ERROR(
[Couldn't find grump.h...try downloading the source from \
http://www.grumpalot.org] )])
        </PRE
></TD
></TR
></TABLE
><P
>          This macro will spit out an acknowledgment message while
          configure is running, either an affirmative if it finds the
          file:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>checking for grump.h... yes
        </PRE
></TD
></TR
></TABLE
><P
>          or a negative, if it can't find the file:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>checking for grump.h... no
configure: error: Couldn't find grump.h...try downloading the
source from http://www.grumpalot.org...
        </PRE
></TD
></TR
></TABLE
><P
>          Several things can cause this check to fail. The header file
          must first exist; the user must also have permission to read
          it. To perform the check, the configure script creates a
          very simple C program that consists more or less of a single
          #include statement for the supplied header file, in our case
          grump.h.  The configure script then tries to compile it,
          adding the contents of the CPPFLAGS environment variable to
          the compile line. Whoever is compiling the software will
          have to add any include paths to CPPFLAGS that aren't
          implicitly checked by the compiler. If the header files are
          installed in a nonstandard location, such as /opt/include,
          and CPPFLAGS doesn't refer to that directory-for example, as
          -I/opt/include-the AC_CHECK_HEADER macro will fail, even
          though the files do exist on the system. However, this is an
          issue for the system's administrator. Part of the
          convenience of autoconf is that you, as the developer,
          don't need to worry about these details.
        </P
><P
>          If you have a lot of header files to check for, or only want
          to find one out of a list of multiple header files, you can
          use AC_CHECK_HEADERS. The format for AC_CHECK_HEADERS is the
          same as with AC_CHECK_HEADER, except that you can list
          multiple files, separated by spaces, in the first
          parameter. The following example will search for three
          header files. It will call AC_DEFINE to add a #define
          statement to config.h (or DEFS) for the first one it
          finds. If it doesn't find any of them, it will produce an
          error message and bail out of the configure script.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_HEADERS(grump.h grump-linux.h grump-win32.h, break,
AC_MSG_ERROR([Couldn't find grump.h...try downloading the source \
from http://www.grumpalot.org] ))
        </PRE
></TD
></TR
></TABLE
><P
>          If configure finds grump-linux.h, it will create a #define
          statement for HAVE_GRUMP_LINUX_H and so on, which you can
          check for in your code. If you want to check for all the
          listed header files, simply omit the break command.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN384"
>Custom Checks</A
></H2
><P
>          You can also check for the existence of specific programs,
          libraries, and even single function calls. Let's start with
          the program macros.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
> AC_CHECK_PROG (VARIABLE, PROG-TO-CHECK-FOR, VALUE-IF-FOUND [,
          VALUE-IF-NOT-FOUND [, PATH, [ REJECT ]]])
 AC_CHECK_PROGS (VARIABLE, PROGS-TO-CHECK-FOR [,
          VALUE-IF-NOT-FOUND [, PATH]])
        </PRE
></TD
></TR
></TABLE
><P
>          Each program check will set an environment variable,
          VARIABLE, with AC_SUBST, according to whether the program is
          found (VALUE-IF-FOUND) or not
          (VALUE-IF-NOT-FOUND). PROG-TO-CHECK-FOR is the file name of
          the program.  You can use the optional parameter PATH to
          override the PATH environment variable, and REJECT to ignore