generating-makefiles.html

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

></TD
></TR
></TABLE
><P
>          The FEATURE is the second half of the enable option. In the
          example that follows, we test for the feature of whether or
          not to generate a separate browsing application. We want
          the option to be --enable-browser, so our FEATURE will be
          simply browser. The HELP-STRING is the text we want to
          display for this option inside the configure --help
          listing. The ACTION parameters are shell script fragments
          that are executed depending on whether or not configure is
          invoked with our --enable option. Typically you will want to
          set a shell variable here; we will use the contents of that
          variable later, for our conditional tests. Our example
          sets the shell variable $enable_browser to whatever value
          is passed into the --enable-browser parameter, or to no if
          the parameter isn't used. The AC_ARG_ENABLE macro always
          sets $enableval to the passed-in value.
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_ARG_ENABLE(browser,
[  --enable-browser  build external browser [default=no]],
enable_browser="$enableval", enable_browser="no")
        </PRE
></TD
></TR
></TABLE
><P
>          Next we must pass the results of this test into the make
          system. We could do this the hard way, by calling AC_SUBST
          and rigging up special support code in both configure.in and
          Makefile.am. Or we could do it the easy way and use the
          support that's already wired into the AM_CONDITIONAL
          macro. This macro takes two parameters: the name of a
          makefile variable, and a shell script command that returns a
          Boolean value. You'll use the first parameter to test for
          the condition in your Makefile.am file; AM_CONDITIONAL calls
          AC_SUBST on this parameter, so it will be available in your
          makefiles. autoconf will insert the second parameter into an
          if/else/fi statement in the configure shell script to set
          the value of the first parameter. The test for our
          theoretical browser might look something like this:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AM_CONDITIONAL(ENABLE_BROWSER, test "$enable_browser" = "yes")
        </PRE
></TD
></TR
></TABLE
><P
>          In your Makefile.am you can include an if/else/endif block
          to test against the first parameter in
          AM_CONDITIONAL. You'll usually want to set one or more
          makefile variables inside the if block to have different
          values for each conditional branch. You can then refer to
          these variables in the rest of your Makefile.am file,
          instead of referring to their contents directly. Here's the
          imaginary Makefile.am file for our browser example:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>if ENABLE_BROWSER
BROWSER_APP = mybrowser
else
BROWSER_APP =
endif

bin_PROGRAMS = mainapp $(BROWSER_APP)

mybrowser_SOURCES = browser_main.c
mainapp_SOURCES = main.c
        </PRE
></TD
></TR
></TABLE
><P
>          Generally it is better to avoid putting the special automake
          variables, like bin_PROGRAMS, inside your if
          statements. automake seems to become confused when you do
          this in certain ways. Thus you should avoid constructs like
          this:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>if ENABLE_BROWSER
bin_PROGRAMS = myapp mybrowser
else
bin_PROGRAMS = myapp
endif
        </PRE
></TD
></TR
></TABLE
><P
>          These if/else/endif blocks are purely an automake construct;
          they don't even make it to the Makefile.in file. When
          automake sees an if block, it creates a separate set of
          variable declarations for each condition, inside the
          Makefile.in file. At configure time, each block of variables
          will either be left alone or commented out, depending on
          which configure options the administrator selects. For
          example, the Makefile file created by running ./configure
          --enable-browser would have the following entries:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>BROWSER_APP = mybrowser
#BROWSER_APP =
        </PRE
></TD
></TR
></TABLE
><P
>          Running configure without --enable-browser would create
          these entries instead:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>#BROWSER_APP = mybrowser
BROWSER_APP =
        </PRE
></TD
></TR
></TABLE
><P
>          You can also base your AM_CONDITIONAL tests on the results
          of other autoconf macros. This is easy with the AC_CHECK_*
          macros. All you have to do is call the true command for
          ACTION-IF-FOUND, and the false command for
          ACTION-IF-NOT-FOUND. Gnome-libs uses the following test to
          optionally extract documentation from the source files if
          the gtkdoc-mkdb utility exists:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>AC_CHECK_PROG(GTKDOC, gtkdoc-mkdb, true, false)
AM_CONDITIONAL(HAVE_GTK_DOC, $GTKDOC)
        </PRE
></TD
></TR
></TABLE
><P
>          These basic tools are very flexible if you know how to use
          them. You are free to use whatever conditional tests you
          need, and you can choose whatever variable names are most
          descriptive for the task at hand. If you do run into
          trouble, don't hesitate to crack open the generated Makefile
          and see what's going on inside. Try changing subtle parts
          of your Makefile.am file and see how those changes affect
          Makefile. Run the configure script with different op-
          tions. You can learn a lot with commands like
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>diff -u Makefile.before Makefile.after
        </PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN499"
>Cutting a Distribution</A
></H2
><P
>          Creating a source code distribution is very easy with an
          automake project.  You practically get it for free. automake
          always creates a make dist target in your topmost
          makefile. This target grabs the distributable files in your
          project tree, and runs tar and gzip on them to create a file
          of the form PACKAGE-VERSION.tar.gz, using the values of
          PACKAGE and VERSION from the AM_INIT_AUTOMAKE macro.
        </P
><P
>          In addition, automake creates the make distcheck target, a
          superset of make dist that will create the compressed
          archive, or tarball, extract it into a temporary directory,
          attempt to build it, and then report on whether or not the
          build was successful. This is a good way to make sure your
          distribution is in good shape, that you haven't forgotten to
          include any necessary files, and that your code compiles all
          the way through without errors. The distcheck target cleans
          up its mess, leaving only the tarball. Note that distcheck
          only verifies the build process; it does not try to actually
          run the application, so it won't pick up any runtime
          problems.
        </P
><P
>          By default, automake distributes any files you list under
          the _SOURCES and _HEADERS primaries. A complete distribution
          requires many other standard files, many of which are
          created by configure, libtoolize, and other utili-
          ties. automake implicitly includes these in any distribution
          it creates. You can get a full list of these files by
          running automake --help.
        </P
><P
>          To make life easier for users of your distributions,
          automake also includes the Makefile.in files from your
          source tree. This means that the automake and autoconf
          packages are not a requirement for anyone installing the
          distribution.  The user needs only run the provided
          configure script, which in turn translates the Makefile.in
          files into Makefile files. To avoid grabbing any rogue
          Makefile.in files in your source tree that don't actually
          belong in the distribution, automake scans through the
          master list of generated files in AC_OUTPUT.
        </P
><P
>          This takes care of all the files automake will automatically
          put into a distribution. In many projects this will cover
          all the files you need to distribute: the source code and
          the prepackaged build system. However, sometimes you will
          have additional files that are important to your application
          but aren't necessarily source code or build scripts. You
          might have some graphics or sound files, or end user
          documentation, or shell scripts. automake provides a
          catchall variable, EXTRA_DIST, where you can list all
          these extra files. Also, since EXTRA_DIST does not have to
          pass through the make process, it is not subject to
          limitations from the makefile subdirectory boundaries. For
          this reason you can include files in subdirectories;
          furthermore, if you add a directory name to EXTRA_DIST,
          automake recursively copies that entire directory into the
          distribution. This feature is great if you have many media
          files to distribute and don't want to have to create a
          Makefile.am file for every subdirectory.
        </P
><P
>          Occasionally you will need to do some processing of the
          distribution tree just before make dist archives it. Perhaps
          you need to patch up some files, or remove an intermediate
          file that's listed in a _SOURCES variable but shouldn't
          actually be distributed. To handle this task, automake
          supplies a customized dist-hook target. You can declare this
          target inside your Makefile.am file, using the $(distdir)
          variable to refer to any files or paths inside the distri-
          bution directory. For example, to move a directory of
          graphics files from extra/media/graphics to browser/graphics
          in the distribution, you could add the following to
          Makefile.am:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>dist-hook:
    mv $(distdir)/extra/media/graphics $(distdir)/browser/graphics
        </PRE
></TD
></TR
></TABLE
><P
>          A common courtesy in any complex software package is the
          test suite. According to the GNU standards, the make check
          target builds and optionally runs this test suite but does
          not install it. You should always write your test suites to
          run inside the source tree, prior to installation. If the
          administrator has to install your software before running
          the test suite, the whole purpose of the test suite is
          defeated.
        </P
><P
>          To set up a check target, add the check_PROGRAMS variable to
          your Makefile.am file, and a corresponding _SOURCES
          primary. If you stop there, the make check target will build
          the test programs but will not run them. You can get make
          check to automatically run the tests and produce a report of
          which ones passed and which ones failed by adding your test
          programs to the TESTS variable in Makefile.am:
        </P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>TESTS = myapp-test
check_PROGRAMS = myapp-test
myapp_test_SOURCES = myapp-test.c
        </PRE
></TD
></TR
></TABLE
></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="creating-configuration.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="dealing-with-libraries.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Creating Your Own Configuration</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="gnome-build.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Dealing with Libraries</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>