Autoconf, Automake, and Libtool
<<< PreviousNext >>>

A Minimal GNU Autotools Project

This chapter describes how to manage a minimal project using the GNU Autotools. A minimal project is defined to be the smallest possible project that can still illustrate a sufficient number of principles in using the tools. By studying a smaller project, it becomes easier to understand the more complex interactions between these tools when larger projects require advanced features.

The example project used throughout this chapter is a fictitious command interpreter called foonly. foonly is written in C, but like many interpreters, uses a lexical analyzer and a parser expressed using the lex and yacc tools. The package will be developed to adhere to the GNU Makefile standard, which is the default behavior for Automake.

There are many features of the GNU Autotools that this small project will not utilize. The most noteworthy one is libraries; this package does not produce any libraries of its own, so Libtool will not feature in this chapter. The more complex projects presented in the chapter called A Small GNU Autotools Project and the chapter called A Large GNU Autotools Project will illustrate how Libtool participates in the build system. The purpose of this chapter will be to provide a high-level overview of the user-written files and how they interact.

User-Provided Input Files

The smallest project requires the user to provide only two files. The remainder of the files needed to build the package are generated by the GNU Autotools (see the section called Generated Output Files).

I like to think of Makefile.am as a high-level, bare-bones specification of a project's build requirements: what needs to be built, and where does it go when it is installed? This is probably Automake's greatest strength-the description is about as simple as it could possibly be, yet the final product is a Makefile with an array of convenient make targets.

The configure.in is a template of macro invocations and shell code fragments that are used by autoconf to produce a configure script (see the chapter called Generated File Dependencies). autoconf copies the contents of configure.in to configure, expanding macros as they occur in the input. Other text is copied verbatim.

Let's take a look at the contents of the user-provided input files that are relevant to this minimal project. Here is the Makefile.am: 
     bin_PROGRAMS = foonly
     foonly_SOURCES = main.c foo.c foo.h nly.c scanner.l parser.y
     foonly_LDADD = @LEXLIB@

This Makefile.am specifies that we want a program called foonly to be built and installed in the bin directory when make install is run. The source files that are used to build foonly are the C source files main.c, foo.c, nly.c and foo.h, the lex program in scanner.l and a yacc grammar in parser.y. This points out a particularly nice aspect about Automake: because lex and yacc both generate intermediate C programs from their input files, Automake knows how to build such intermediate files and link them into the final executable. Finally, we must remember to link a suitable lex library, if configure concludes that one is needed.

And here is the configure.in: 
     dnl Process this file with autoconf to produce a configure script.
     AC_INIT(main.c)
     AM_INIT_AUTOMAKE(foonly, 1.0)
     AC_PROG_CC
     AM_PROG_LEX
     AC_PROG_YACC
     AC_OUTPUT(Makefile)

This configure.in invokes some mandatory Autoconf and Automake initialization macros, and then calls on some Autoconf macros from the AC_PROG family to find suitable C compiler, lex, and yacc programs. Finally, the AC_OUTPUT macro is used to cause the generated configure script to output a Makefile--but from what? It is processed from Makefile.in, which Automake produces for you based on your Makefile.am (see the chapter called Generated File Dependencies).

<<< PreviousHomeNext >>>
Suffix rules Generated Output Files