creating-configuration.html

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

          specific path-program combinations-for example, if you
          know that more than one program has the same name, blahblah,
          and that the version you don't want is always at
          /usr/bin/blahblah.
        </P
><P
>          The AC_CHECK_PROGS macro does pretty much the same thing,
          except you can provide a list of programs to search
          for. AC_CHECK_PROGS places the first program it finds into
          VARIABLE. Here's an example that checks for the fictitious
          program zed.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_PROGS(ZED, zed zed2000 zed-x11, "")
AC_CHECK_PROG(USE_ZED_X11, zed-x11, yes, no)
        </PRE
></TD
></TR
></TABLE
><P
>          First it looks for zed in the normal PATH-first as zed, then
          as zed2000 and zed-x11. If it finds any of these versions of
          zed, it sets the ZED variable to that value and uses
          AC_SUBST to substitute it into the makefile. In the second
          macro it checks for the existence of zed-x11 and sets the
          USE_ZED_X11 environment variable to yes if it does find it
          and no if it doesn't. The result is that $(ZED) will be set
          to whichever version of zed the user has installed, but if
          the user happens to have zed-x11 installed, extra support
          for the X11 version can be conditionally compiled on the
          target system, according to the value of $USE_ZED_X11. Note
          that nothing magic happens in your code because of an
          autoconf macro. You still have to check for the USE_ZED_X11
          in the makefile and add the proper conditional blocks to
          enable or disable the extra support.  In Section 3.3.4 we'll
          see how to do this with the AM_CONDITIONAL macro.
        </P
><P
>          When checking for libraries, you give the name of the
          library and an important function name within that
          library. By allowing you to name a specific function to
          search for, autoconf lets you check for specific
          functionality in a library. Often many similar
          implementations are floating around for the same li-
          brary. A good example is the standard C library. On
          different platforms, libc may or may not contain certain
          common functions, like vsnprintf( ) and strcasecmp( ). The
          version number of the library isn't much help because
          there's no universal correspondence between the version
          number and the functions a library contains. Version 2.1 of
          libc on platform A might have vsnprintf( ), while version
          5.0 of libc on platform B might not. Version number checks
          would quickly deteriorate into a swampy maze of special
          cases, and they require intricate knowledge of the histories
          of each platform. It's so much easier just to check for the
          function directly.
        </P
><P
>          The AC_CHECK_LIB macro uses a technique similar to that of
          AC_CHECK_HEADER. AC_CHECK_LIB creates and compiles a simple
          temporary program that calls the function, passing the
          library in on the link line. If the program compiles
          successfully, AC_CHECK_LIB knows that the function exists in
          that library. If compilation fails, it knows that the
          function doesn't exist there, even though it might be
          somewhere else on the system. It's possible to nest
          successive calls to AC_CHECK_LIB, so you can specify
          alternate libraries to search for the function if the first
          try fails (stay tuned for more on that feature).
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_LIB (LIBRARY, FUNCTION [, ACTION-IF-FOUND [,
          ACTION-IF-NOT-FOUND [, OTHER-LIBRARIES]]])
        </PRE
></TD
></TR
></TABLE
><P
>          LIBRARY is the base name of the library; if you were
          checking for libgrump.so, you would pass in grump. The
          following macro would check for the grump_some( ) function
          in libgrump.so or libgrump.a:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_LIB(grump, grump_some)
        </PRE
></TD
></TR
></TABLE
><P
>          The default action is to add the library to the LIBS
          variable and create a special #define statement for it with
          AC_DEFINE. In our grump example, AC_CHECK_LIB would add
          -lgrump to LIBS and the #define statement HAVE_LIBGRUMP to
          config.h if it found libgrump.so or libgrump.a. If the li-
          brary you're searching has additional library dependencies,
          you may have to add those as the OTHER-LIBRARIES
          parameter. If libgrump.so required libcrypt, you would do
          this instead:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_LIB(grump, grump_some, , , -lcrypt)
        </PRE
></TD
></TR
></TABLE
><P
>          AC_CHECK_LIB will automatically create the #define
          HAVE_LIBxxx statement for you to use in your source code,
          but if you need to perform any special custom actions at
          configure time, you can add shell script code or other m4
          macros to the ACTION-IF-FOUND and ACTION-IF-NOT-FOUND
          parameters. The NOT-FOUND parameter is a good place to
          perform nested library checks. In our example, if the
          grump_some( ) function were instead located in the
          libgrumpus library on certain platforms, you could invoke a
          fallback check for it like this:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_LIB(grump, grump_some, ,
    [ AC_CHECK_LIB(grumpus, grump_some) ],
    -lcrypt)
        </PRE
></TD
></TR
></TABLE
><P
>          If you need a specific function and don't care which library
          it resides in, you can check for it with the AC_CHECK_FUNCS
          macro. Simply provide a list of function names, and for each
          one it finds, AC_CHECK_FUNCS will define HAVE_FUNCTION.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_FUNCS (FUNCTION... [, ACTION-IF-FOUND [,
          ACTION-IF-NOT-FOUND]])
        </PRE
></TD
></TR
></TABLE
><P
>          The following call to AC_CHECK_FUNCS will potentially result
          in one or more of the following define statements:
          HAVE_VPRINTF, HAVE_SETENV, and HAVE_STRCHR.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_FUNCS(vprintf setenv strchr)
        </PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN405"
>Helper Tools</A
></H2
><P
>          Figuring out which macros to include in your configure.in
          file can be a Herculean task. Without broad experience in
          porting and cross-compiling, you'll probably end up guessing
          which functions and libraries you need to test for.  Do all
          platforms have native support for inline functions? Should
          you bother checking for vsnprintf( )? Who knows?
        </P
><P
>          The autoconf package has a helper utility called autoscan
          that snoops through your source files looking for common
          portability problems. It generates a fully formed-but
          typically quite lean-configure.in file for you. By default
          it saves this file as configure.scan. You'll still have to
          do some work to customize the configure.scan file.
        </P
><P
>          Another helpful tool is ifnames, a utility to extract and
          sort all the preprocessor define statements in your source
          files. You invoke ifnames with a list of file names (you can
          also pipe the files to ifnames through stdin), and it spits
          back a sorted list of all the #if, #ifdef, #elif, and
          #ifndef statements it finds. This is especially useful if
          you are adding autoconf support to an existing software
          package.
        </P
><P
>          If you are using a config.h file, you may want to try out
          the autoheader tool. autoheader automatically creates the
          config.h.in file for you on the basis of the macros you
          call in configure.in. In particular, autoheader looks for
          any calls to AC_DEFINE, plus any HAVE_* definitions created
          by the AC_CHECK_* macros. These preprocessor statements must
          be undefined (by #undef) in a file called acconfig.h (unless
          you specify the value in the optional second parameter to
          AC_DEFINE). The undefinitions are inserted into config.h to
          protect autoconf's declarations from declarations that might
          coincidentally occur in external header files. Autoconf
          comes with an acconfig.h of its own that supplies most of
          the common #undef statements you'll need. If you create new
          ones, you have to add them to a new acconfig.h file in your
          source directory. autoheader combines both of these when it
          creates config.h.in. This tool can save you quite a lot of
          work in a large project.
        </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="gnome-build.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="generating-makefiles.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>The GNOME Build Environment</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="gnome-build.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Generating Makefiles</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>