generating-makefiles.html

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

></A
><P
><B
>Figure 3-2. Running aclocal</B
></P
><DIV
CLASS="MEDIAOBJECT"
><P
><IMG
SRC="figures/3f2.png"
></IMG
></P
></DIV
></DIV
><P
>          The automake script also scans configure.in and uses what it
          finds to customize its production of Makefile.in files. A
          prominent example is automake's extra handling of the
          AC_SUBST macro. As we learned earlier, if you call AC_SUBST
          on a shell variable in configure.in, the configure script
          will set up a substitution for your Makefile.in files. For
          example, if you call AC_SUBST(MYVAR), configure will replace
          all occurrences of @MYVAR@ in Makefile.in with the value of
          MYVAR. However, it will not actually add the necessary
          assignment statements. If you are writing your own
          Makefile.in files, you will have to add a line like this to
          make use of that substitution:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>MYVAR = @MYVAR@
        </PRE
></TD
></TR
></TABLE
><P
>          If you're using autoconf only and you don't explicitly add
          it to Makefile.in, your generated Makefile files will not
          contain the MYVAR variable at all. On the other hand, if
          you're using automake, you get all that for free. automake
          creates your Makefile.in files for you, and as part of its
          scanning process it automatically adds these assignment
          lines. Anytime you call AC_SUBST in configure.in, you can be
          assured that that variable will exist in your makefiles,
          with no additional work on your part.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN450"
>Automake Variables</A
></H2
><P
>          Strictly speaking, all Makefile.am files are simply
          Makefile.in files that follow special formatting
          rules. You can use autoconf variable substitutions like
          @VERSION@, as we discussed in Section 3.1.3, inside your
          Makefile.am files.  You can also embed raw makefile rules
          and targets when necessary. automake will copy the entire
          contents of each Makefile.am file into the corresponding
          Makefile.in file; the configure script will then translate
          that Makefile.in into a Makefile file, performing variable
          substitutions as it finds them.
        </P
><P
>          Of course, if that's all automake did, it would be no more
          helpful than the cp command. automake adds quite a few
          makefile targets and rules of its own, based on the syntax
          of the variable names in Makefile.am. Some of these makefile
          targets exist to satisfy the GNU standards we discussed in
          Section 3.3.1. Others exist to make the build system more
          robust and convenient. For example, automake adds
          dependencies on most of the generated files in the build
          system, such as the configure script, the Makefile.in and
          Makefile files, and even config.h. If any of these files
          have been touched, a simple make command will trigger a
          rebuild of the affected files. If you tweaked a line in a
          Makefile.am file in a subdirectory, make will rerun automake
          for you before continuing.
        </P
><P
>          Part of what allows the automake system to express so much
          about the make process in so few commands is the elegance of
          its naming scheme. When automake parses Makefile.am, it
          looks for a special type of variable name.  When it finds
          the special variables, it creates the necessary makefile
          targets to handle the contents of that variable properly.
        </P
><P
>          These special variables take the form of
          target_PRIMARY. target specifies where the contents are
          supposed to go; PRIMARY tells automake what to do with those
          contents. automake supports three general types of
          primaries, each of which determines what sort of contents
          the variable can contain: binary files, source files, and
          linker options.
        </P
><P
>          The first type of primary declares binary targets, such as
          libraries and executables. A variable with the _PROGRAMS
          primary holds a list of one or more executables; the
          _LIBRARIES and _LTLIBRARIES primaries both refer to librar-
          ies. Use _LIBRARIES to create static-only libraries. The
          _LTLIBRARIES primary invokes the libtool script to create
          static and dynamic libraries in a platform-independent
          manner. We'll explore library creation in greater depth in
          Section 3.4.
        </P
><P
>          The target name for these primaries should indicate the
          install location for the binary files listed in the
          variable's contents. The most common variations you'll use
          are bin_PROGRAMS, lib_LIBRARIES, and lib_LTLIBRARIES. The
          bin and lib target names correspond directly to the
          $(bindir) and $(libdir) variables. Thus with the
          bin_PROGRAMS variable you can specify a list of programs
          you want installed into whichever $(bindir) directory the
          administrator specifies at configure time. Here are a few
          examples:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>bin_PROGRAMS = myfirstapp mysecondapp
lib_LIBRARIES = libdothis.a libdothat.a
lib_LTLIBRARIES = libmylibtoollibrary.la
        </PRE
></TD
></TR
></TABLE
><P
>          You may not always want to install all of your binary
          files. Sometimes the build process works better if you
          create transient convenience libraries; if the source code
          for your target executable is spread across multiple
          subdirectories, you may have to build a static library for
          each subdirectory. However, you don't want to install these
          convenience libraries. They're part of the journey, not the
          destination. The noinst target exists for this very
          reason. Any files listed under noinst will be built but not
          installed. If libdothis.a and libdothat.a in the example
          here were convenience libraries, we would change the
          _LIBRARIES declaration to this:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>noinst_LIBRARIES = libdothis.a libdothat.a
        </PRE
></TD
></TR
></TABLE
><P
>          Sometimes you'll have binary files that you do want
          installed but may or may not want built each time, depending
          on how configure is invoked. The EXTRA target covers this
          situation. For example, if you wanted automake always to
          build myfirstapp, but to build mysecondapp only if configure
          added it to the @extra_app@ variable substitution, you could
          list the optional mysecondapp binary in an EXTRA_PROGRAMS
          variable, and myfirstapp and @extra_app@ in the regular
          bin_PROGRAMS variable:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>EXTRA_PROGRAMS = mysecondapp
bin_PROGRAMS = myfirstapp @extra_app@
        </PRE
></TD
></TR
></TABLE
><P
>          Then, if @extra_app@ were empty, the makefile would build
          only myfirstapp; on the other hand, if @extra_app@ contained
          mysecondapp, the makefile would build both. automake can't
          just guess at the contents of @extra_app@ because it needs a
          concrete target name to create the proper de-
          pendencies. The EXTRA automake target provides you with a
          place to declare it.
        </P
><P
>          The second category of primaries refers to lists of source
          code files. The _SOURCES primary, one of the most commonly
          used primaries, lists source files that must be compiled
          into object files. These source files are then linked into
          an executable or library declared in a _PROGRAMS,
          _LIBRARIES, or _LTLIBRARIES primary. You don't have to
          include any of your header files in Makefile.am unless you
          want to install them on the target system. In this case you
          list the public header files inside a _HEADERS primary,
          using the same target convention we used for the _PROGRAMS
          primary. So, if we had a myapp.h and an otherstuff.h file
          that we wanted to install into $(includedir), we would
          declare the following variable:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>include_HEADERS = myapp.h otherstuff.h
        </PRE
></TD
></TR
></TABLE
><P
>          The target directory concept is very simple and
          flexible. automake does not do any unusual processing to the
          "include" phrase from "include_HEADERS" when converting it
          into a reference to $(includedir). It simply wraps it with
          "$(-dir)". In fact, you can define your own directory
          variables and use them with a primary, just like the include
          target. You may need to do this if you want to install
          header files into a subdirectory of $(includedir). To
          install the header files we've mentioned here into the
          $(includedir)/myapp directory, you could do something like
          this:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>myappdir = $(includedir)/myapp
myapp_HEADERS = myapp.h otherstuff.h
        </PRE
></TD
></TR
></TABLE
><P
>          So far, we know how to tell automake where to install our
          files, but how do we tell it which source files belong with
          which binary? How do we declare that, for example, main1.c
          and flubber.c should end up in the myfirstapp executable,
          and main2.c and dingbat.c are for mysecondapp? The _PROGRAMS
          primary sets up the target directory for the executable
          file. We don't need to install the .c files, so it makes
          no sense to use a directory target for the _SOURCES
          primary. Instead we use the name of the corresponding binary
          as the target for the _SOURCES primary (you can also do this
          with _HEADERS primaries):
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>myfirstapp_SOURCES = main1.c flubber.c
mysecondapp_SOURCES = main2.c dingbat.c
        </PRE
></TD
></TR
></TABLE
><P
>          The library primaries work similarly, with a small caveat:
          Because the period is not a legal character for makefile
          variables, we cannot have a libdothis.a_SOURCES variable. We
          must canonicalize it by converting the questionable
          punctuation into underscores, producing libdothis_a_SOURCES
          instead. automake expects to see underscores, not hyphens or
          any other canonicalized character, so don't be creative
          here. There's only one way to canonicalize an automake
          variable. The libraries we've already mentioned would look
          like this:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>libdothis_a_SOURCES = dothis.c
libdothat_a_SOURCES = dothat.c
libmylibtoollibrary_la_SOURCES = dotheotherthing.c
        </PRE
></TD
></TR
></TABLE
><P
>          The _SOURCES and _HEADERS primaries provide a means for you
          to inform automake about the important compilable and
          distributable source code files in your project. automake
          supports some less frequently used primaries for other types
          of files. For miscellaneous architecture-independent data
          files, you can use the _DATA primary. This works well for
          HTML files, as well as special configuration files like the
          GNOME desktop files (see Section 5.6). By default, _DATA
          files are not included in a distribution of your project, so
          you will have to remind automake to include them by listing
          them in the EXTRA_DIST variable (see Section 3.3.5).
        </P
><P
>          Other related primaries include _SCRIPTS for shell scripts,
          Perl scripts, and the like; _MANS for man pages; _TEXINFOS
          for Texinfo documentation; and a few others. Check the
          automake documentation for more information on how to use
          these primaries.
        </P
><P
>          The final category of primaries holds command line options
          for the linker.  The _LDFLAGS primary lets you define a list
          of miscellaneous linker flags for a specific target that
          don't belong with the other library primaries; it's a
          catchall.  Any variables that use the _LDADD or _LIBADD
          primaries should contain only object files, libraries (-l),
          and library paths (-L) to be linked into a specific ex-
          ecutable (_LDADD) or library (_LIBADD). You cannot mix the
          contents of any of these three primaries. automake is very
          particular about what goes into these primaries and will
          bail out with an error if you misuse them.
        </P
><P
>          Here's what we would do to link our libdothis.a and
          libdothat.a libraries into our myfirstapp executable:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>myfirstapp_LDADD = -ldothis -ldothat
        </PRE
></TD
></TR
></TABLE
><P
>          We'll go into the specifics of the linker primaries in
          Section 3.4.1.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN478"
>Conditional Compiling</A
></H2
><P
>          Sooner or later you'll want to add support for optional
          features to one of your projects. Many different approaches
          have developed over the years for handling this-some of
          them tidy, and some of them not so tidy. The autoconf and
          automake systems work together to provide a clean, simple,
          flexible solution.  Through autoconf you can add command
          line parameters to the configure script that allow
          administrators to turn your extra features on or
          off. Automake allows you to express the conditions with
          familiar if/else/endif statements inside your Makefile.am
          files.
        </P
><P
>          First we'll discuss setting up the command line
          parameters. We can add any number of --enable options to the
          configure script-one per invocation-with another m4 macro,
          AC_ARG_ENABLE. The macro takes the following form:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_ARG_ENABLE (FEATURE, HELP-STRING [, ACTION-IF-GIVEN [,
  ACTION-IF-NOT-GIVEN]])
        </PRE