$ autoconf$ ls -l-rw-rw-r--  1 jsheets  jsheets      0 Jul  3 14:52 Makefile.in-rwxrwxr-x  1 jsheets  jsheets  26817 Jul  3 14:52 configure*-rw-rw-r--  1 jsheets  jsheets     36 Jul  3 14:52 configure.in-rw-rw-r--  1 jsheets  jsheets      0 Jul  3 14:52 main.c        </PRE></TD></TR></TABLE><P>          The autoconf command parses the configure.in macro file and          expands it into the configure shell script file. But look at          the size of it: 26,000 bytes- almost 800 lines for a script          that doesn't do anything. Where is autoconf getting all          those bytes?        </P><P>          Take a look at it in your favorite editor. You'll see a very          long list of variable declarations, most of them at first          glance quite cryptic. You'll also see the code that          generates the --help listing. The configure script is pretty          well commented, so if you're curious about how it works,          you should be able to learn a lot by studying it. Of          particular note are the last couple hundred lines of the          file; this code creates two files: config.cache and          config.status. The first is a temporary file for storing the          test results between successive calls to configure, so that          configure doesn't have to run time-consuming tests every          time. If configure finds the results of a test in          config.cache, it grabs the results from there rather than          running the test again.        </P><P>          The second file, config.status, is another shell script,          used to convert foo.in files into foo files by performing          variable substitution (as described in Section 3.1.3). Most          of this processing is simple text replacement, to          customize certain files according to configure's test          results.  For example, if configure discovers that a system          uses the GNU gawk tool instead of the standard variant, awk,          it can insert the string "gawk" directly into the Makefile          file on that system.        </P><P>          Most of the time you won't have to worry about these two          files. You'll just run configure, and configure will take          care of the rest. If you make a change to configure.in that          involves a cached test result, you may have to delete the          old config.cache file to force configure to run the test          again from scratch. The only time you would want to run          config.status by hand might be to regenerate your makefiles          according to the current set of configure options; if you          modified a makefile during testing and wanted to restore          it, you could delete it and then run config.status to          recreate it in its original form from the Makefile.in file.        </P><P>          Let's try running the configure script we created          earlier. Here's a sample session:        </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ ./configurecreating cache ./config.cacheupdating cache ./config.cachecreating ./config.statuscreating Makefile$ ls -lt-rw-rw-r--  1 jsheets  jsheets      0 Jul  3 14:58 Makefile-rw-rw-r--  1 jsheets  jsheets    127 Jul  3 14:58 config.log-rw-rw-r--  1 jsheets  jsheets    768 Jul  3 14:58 config.cache-rwxrwxr-x  1 jsheets  jsheets   4576 Jul  3 14:58 config.status*-rwxrwxr-x  1 jsheets  jsheets  26817 Jul  3 14:52 configure*-rw-rw-r--  1 jsheets  jsheets      0 Jul  3 14:52 Makefile.in-rw-rw-r--  1 jsheets  jsheets      0 Jul  3 14:52 main.c-rw-rw-r--  1 jsheets  jsheets     36 Jul  3 14:52 configure.in        </PRE></TD></TR></TABLE><P>          We have four new files. Figure 3.1 shows the process          graphically. Aside from the config.cache and config.status          files we saw in the configure listing, we also see the          config.log file (empty except for the opening comments          because we didn't run any real tests), and the Makefile file          generated from Makefile.in. The config.log file is good for          debugging the configuration process. As configure chugs          along, it dumps its test results into config.log.  When          tests fail with cryptic errors, you can often find out more          about the failure by looking at this file.        </P><DIVCLASS="FIGURE"><ANAME="AEN314"></A><P><B>Figure 3-1. Running the configure Script</B></P><DIVCLASS="MEDIAOBJECT"><P><IMGSRC="figures/3f1.png"></IMG></P></DIV></DIV></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN319">Makefile Variable Substitution</A></H2><P>          Since our Makefile.in file in Section 3.1.2 was empty, the          output file, Makefile, was also empty. Let's try putting          something in Makefile.in to see what we get. We'll start          with a simple comment:        </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ echo "# This is Makefile.in" &#62; Makefile.in$ ./configureloading cache ./config.cachecreating ./config.statuscreating Makefile$ cat Makefile# Generated automatically from Makefile.in by configure.# This is Makefile.in        </PRE></TD></TR></TABLE><P>          The entire contents of Makefile.in were copied into          Makefile, along with a reminder that the Makefile was not          handwritten.        </P><P>          Next we'll attempt some variable substitution to see how          configure passes information to your compiler. This is where          things start to get a little more complex. The first step is          to add the variable substitution to configure.in.  The next          time the autoconf script parses configure.in, the new          variable will show up in the configure script as part of          config.status. Since config.status creates the makefiles, it          must also handle the variable substitutions. So let's get          started. Change your configure.in file to look like Listing          3.1.        </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">Listing 3.1 configure.in with Variable SubstitutionsAC_INIT(main.c)VERSION="0.0.1"AC_SUBST(VERSION)AC_OUTPUT(Makefile)        </PRE></TD></TR></TABLE><P>          VERSION will become a shell script variable in          configure. Anything that is not a special macro will be          copied verbatim from configure.in to configure.  But this is          not what we want. As soon as configure is done running, the          shell process will die and the value of VERSION will be          lost. That's where the AC_SUBST macro comes into          play. AC_SUBST adds VERSION to the list of variables on          which substitutions will be performed. In fact, all          substitutions in config.status are put there by AC_SUBST at          some time or another.        </P><P>          To make sure the wrong substitutions don't take place,          config.status looks only for variables delimited with the          symbol @. Thus to substitute the value of our VERSION shell          script variable into Makefile, we must refer to it as          "@VERSION@" in Makefile.in. Perform the following commands          to see how it works:        </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ echo "# Makefile for version @VERSION@" &#62; Makefile.in$ echo "VERSION = @VERSION@" &#62;&#62; Makefile.in$ cat Makefile.in# Makefile for version @VERSION@VERSION = @VERSION@$ autoconf$ ./configureloading cache ./config.cachecreating ./config.statuscreating Makefile$ cat Makefile# Generated automatically from Makefile.in by configure.# Makefile for version 0.0.1VERSION = 0.0.1        </PRE></TD></TR></TABLE><P>          Remember, if you fail to run autoconf after altering          configure.in, none of your changes will propagate to your          makefiles.        </P></DIV></DIV></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLEWIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="gnome-intro.html">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="index.html">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="creating-configuration.html">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">GNOME</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top">&nbsp;</TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">Creating Your Own Configuration</TD></TR></TABLE></DIV></BODY></HTML>