Subversion Repositories openrisc_2011-10-31

This is configure.info, produced by makeinfo version 4.8 from

.././etc/configure.texi.

INFO-DIR-SECTION GNU admin

START-INFO-DIR-ENTRY

* configure: (configure).       The GNU configure and build system

END-INFO-DIR-ENTRY

   This file documents the GNU configure and build system.

   Copyright (C) 1998 Cygnus Solutions.

   Permission is granted to make and distribute verbatim copies of this

manual provided the copyright notice and this permission notice are

preserved on all copies.

   Permission is granted to copy and distribute modified versions of

this manual under the conditions for verbatim copying, provided that

the entire resulting derived work is distributed under the terms of a

permission notice identical to this one.

   Permission is granted to copy and distribute translations of this

manual into another language, under the above conditions for modified

versions, except that this permission notice may be stated in a

translation approved by the Foundation.

File: configure.info,  Node: Top,  Next: Introduction,  Up: (dir)

GNU configure and build system

******************************

The GNU configure and build system.

* Menu:

* Introduction::                Introduction.

* Getting Started::             Getting Started.

* Files::                       Files.

* Configuration Names::         Configuration Names.

* Cross Compilation Tools::     Cross Compilation Tools.

* Canadian Cross::              Canadian Cross.

* Cygnus Configure::            Cygnus Configure.

* Multilibs::                   Multilibs.

* FAQ::                         Frequently Asked Questions.

* Index::                       Index.

File: configure.info,  Node: Introduction,  Next: Getting Started,  Prev: Top,  Up: Top

1 Introduction

**************

This document describes the GNU configure and build systems.  It

describes how autoconf, automake, libtool, and make fit together.  It

also includes a discussion of the older Cygnus configure system.

   This document does not describe in detail how to use each of the

tools; see the respective manuals for that.  Instead, it describes

which files the developer must write, which files are machine generated

and how they are generated, and where certain common problems should be

addressed.

   This document draws on several sources, including the autoconf

manual by David MacKenzie (*note autoconf overview: (autoconf)Top.),

the automake manual by David MacKenzie and Tom Tromey (*note automake

overview: (automake)Top.), the libtool manual by Gordon Matzigkeit

(*note libtool overview: (libtool)Top.), and the Cygnus configure

manual by K. Richard Pixley.

* Menu:

* Goals::                       Goals.

* Tools::                       The tools.

* History::                     History.

* Building::                    Building.

File: configure.info,  Node: Goals,  Next: Tools,  Up: Introduction

1.1 Goals

=========

The GNU configure and build system has two main goals.

   The first is to simplify the development of portable programs.  The

system permits the developer to concentrate on writing the program,

simplifying many details of portability across Unix and even Windows

systems, and permitting the developer to describe how to build the

program using simple rules rather than complex Makefiles.

   The second is to simplify the building of programs distributed as

source code.  All programs are built using a simple, standardized, two

step process.  The program builder need not install any special tools in

order to build the program.

File: configure.info,  Node: Tools,  Next: History,  Prev: Goals,  Up: Introduction

1.2 Tools

=========

The GNU configure and build system is comprised of several different

tools.  Program developers must build and install all of these tools.

   People who just want to build programs from distributed sources

normally do not need any special tools beyond a Unix shell, a make

program, and a C compiler.

autoconf

     provides a general portability framework, based on testing the

     features of the host system at build time.

automake

     a system for describing how to build a program, permitting the

     developer to write a simplified `Makefile'.

libtool

     a standardized approach to building shared libraries.

gettext

     provides a framework for translation of text messages into other

     languages; not really discussed in this document.

m4

     autoconf requires the GNU version of m4; the standard Unix m4 does

     not suffice.

perl

     automake requires perl.

File: configure.info,  Node: History,  Next: Building,  Prev: Tools,  Up: Introduction

1.3 History

===========

This is a very brief and probably inaccurate history.

   As the number of Unix variants increased during the 1980s, it became

harder to write programs which could run on all variants.  While it was

often possible to use `#ifdef' to identify particular systems,

developers frequently did not have access to every system, and the

characteristics of some systems changed from version to version.

   By 1992, at least three different approaches had been developed:

   * The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael

     Manfredi.

   * The Cygnus configure script, by K. Richard Pixley, and the gcc

     configure script, by Richard Stallman.  These use essentially the

     same approach, and the developers communicated regularly.

   * The autoconf program, by David MacKenzie.

   The Metaconfig program is still used for Perl and a few other

programs.  It is part of the Dist package.  I do not know if it is

being developed.

   In 1994, David MacKenzie and others modified autoconf to incorporate

all the features of Cygnus configure.  Since then, there has been a

slow but steady conversion of GNU programs from Cygnus configure to

autoconf. gcc has been converted, eliminating the gcc configure script.

   GNU autoconf was regularly maintained until late 1996.  As of this

writing in June, 1998, it has no public maintainer.

   Most programs are built using the make program, which requires the

developer to write Makefiles describing how to build the programs.

Since most programs are built in pretty much the same way, this led to a

lot of duplication.

   The X Window system is built using the imake tool, which uses a

database of rules to eliminate the duplication.  However, building a

tool which was developed using imake requires that the builder have

imake installed, violating one of the goals of the GNU system.

   The new BSD make provides a standard library of Makefile fragments,

which permits developers to write very simple Makefiles.  However, this

requires that the builder install the new BSD make program.

   In 1994, David MacKenzie wrote the first version of automake, which

permitted writing a simple build description which was converted into a

Makefile which could be used by the standard make program.  In 1995, Tom

Tromey completely rewrote automake in Perl, and he continues to enhance

it.

   Various free packages built libraries, and by around 1995 several

included support to build shared libraries on various platforms.

However, there was no consistent approach.  In early 1996, Gordon

Matzigkeit began working on libtool, which provided a standardized

approach to building shared libraries.  This was integrated into

automake from the start.

   The development of automake and libtool was driven by the GNITS

project, a group of GNU maintainers who designed standardized tools to

help meet the GNU coding standards.

File: configure.info,  Node: Building,  Prev: History,  Up: Introduction

1.4 Building

============

Most readers of this document should already know how to build a tool by

running `configure' and `make'.  This section may serve as a quick

introduction or reminder.

   Building a tool is normally as simple as running `configure'

followed by `make'.  You should normally run `configure' from an empty

directory, using some path to refer to the `configure' script in the

source directory.  The directory in which you run `configure' is called

the "object directory".

   In order to use a object directory which is different from the source

directory, you must be using the GNU version of `make', which has the

required `VPATH' support.  Despite this restriction, using a different

object directory is highly recommended:

   * It keeps the files generated during the build from cluttering up

     your sources.

   * It permits you to remove the built files by simply removing the

     entire build directory.

   * It permits you to build from the same sources with several sets of

     configure options simultaneously.

   If you don't have GNU `make', you will have to run `configure' in

the source directory.  All GNU packages should support this; in

particular, GNU packages should not assume the presence of GNU `make'.

   After running `configure', you can build the tools by running `make'.

   To install the tools, run `make install'.  Installing the tools will

copy the programs and any required support files to the "installation

directory".  The location of the installation directory is controlled

by `configure' options, as described below.

   In the Cygnus tree at present, the info files are built and

installed as a separate step.  To build them, run `make info'.  To

install them, run `make install-info'. The equivalent html files are

also built and installed in a separate step. To build the html files,

run `make html'. To install the html files run `make install-html'.

   All `configure' scripts support a wide variety of options.  The most

interesting ones are `--with' and `--enable' options which are

generally specific to particular tools.  You can usually use the

`--help' option to get a list of interesting options for a particular

configure script.

   The only generic options you are likely to use are the `--prefix'

and `--exec-prefix' options.  These options are used to specify the

installation directory.

   The directory named by the `--prefix' option will hold machine

independent files such as info files.

   The directory named by the `--exec-prefix' option, which is normally

a subdirectory of the `--prefix' directory, will hold machine dependent

files such as executables.

   The default for `--prefix' is `/usr/local'.  The default for

`--exec-prefix' is the value used for `--prefix'.

   The convention used in Cygnus releases is to use a `--prefix' option

of `/usr/cygnus/RELEASE', where RELEASE is the name of the release, and

to use a `--exec-prefix' option of `/usr/cygnus/RELEASE/H-HOST', where

HOST is the configuration name of the host system (*note Configuration

Names::).

   Do not use either the source or the object directory as the

installation directory.  That will just lead to confusion.

File: configure.info,  Node: Getting Started,  Next: Files,  Prev: Introduction,  Up: Top

2 Getting Started

*****************

To start using the GNU configure and build system with your software

package, you must write three files, and you must run some tools to

manually generate additional files.

* Menu:

* Write configure.in::          Write configure.in.

* Write Makefile.am::           Write Makefile.am.

* Write acconfig.h::            Write acconfig.h.

* Generate files::              Generate files.

* Getting Started Example::     Example.

File: configure.info,  Node: Write configure.in,  Next: Write Makefile.am,  Up: Getting Started

2.1 Write configure.in

======================

You must first write the file `configure.in'.  This is an autoconf

input file, and the autoconf manual describes in detail what this file

should look like.

   You will write tests in your `configure.in' file to check for

conditions that may change from one system to another, such as the

presence of particular header files or functions.

   For example, not all systems support the `gettimeofday' function.

If you want to use the `gettimeofday' function when it is available,

and to use some other function when it is not, you would check for this

by putting `AC_CHECK_FUNCS(gettimeofday)' in `configure.in'.

   When the configure script is run at build time, this will arrange to

define the preprocessor macro `HAVE_GETTIMEOFDAY' to the value 1 if the

`gettimeofday' function is available, and to not define the macro at

all if the function is not available.  Your code can then use `#ifdef'

to test whether it is safe to call `gettimeofday'.

   If you have an existing body of code, the `autoscan' program may

help identify potential portability problems, and hence configure tests

that you will want to use.  *Note Invoking autoscan: (autoconf)Invoking

autoscan.

   Another handy tool for an existing body of code is `ifnames'.  This

will show you all the preprocessor conditionals that the code already

uses.  *Note Invoking ifnames: (autoconf)Invoking ifnames.

   Besides the portability tests which are specific to your particular

package, every `configure.in' file should contain the following macros.

`AC_INIT'

     This macro takes a single argument, which is the name of a file in

     your package.  For example, `AC_INIT(foo.c)'.

`AC_PREREQ(VERSION)'

     This macro is optional.  It may be used to indicate the version of

     `autoconf' that you are using.  This will prevent users from

     running an earlier version of `autoconf' and perhaps getting an

     invalid `configure' script.  For example, `AC_PREREQ(2.12)'.

`AM_INIT_AUTOMAKE'

     This macro takes two arguments: the name of the package, and a

     version number.  For example, `AM_INIT_AUTOMAKE(foo, 1.0)'.  (This

     macro is not needed if you are not using automake).

`AM_CONFIG_HEADER'

     This macro names the header file which will hold the preprocessor

     macro definitions at run time.  Normally this should be

     `config.h'.  Your sources would then use `#include "config.h"' to

     include it.

     This macro may optionally name the input file for that header

     file; by default, this is `config.h.in', but that file name works

     poorly on DOS filesystems.  Therefore, it is often better to name

     it explicitly as `config.in'.

     This is what you should normally put in `configure.in':

          AM_CONFIG_HEADER(config.h:config.in)

     (If you are not using automake, use `AC_CONFIG_HEADER' rather than

     `AM_CONFIG_HEADER').

`AM_MAINTAINER_MODE'

     This macro always appears in Cygnus configure scripts.  Other

     programs may or may not use it.

     If this macro is used, the `--enable-maintainer-mode' option is

     required to enable automatic rebuilding of generated files used by

     the configure system.  This of course requires that developers be

     aware of, and use, that option.

     If this macro is not used, then the generated files will always be

     rebuilt automatically.  This will cause problems if the wrong

     versions of autoconf, automake, or others are in the builder's

     `PATH'.

     (If you are not using automake, you do not need to use this macro).

`AC_EXEEXT'

     Either this macro or `AM_EXEEXT' always appears in Cygnus configure

     files.  Other programs may or may not use one of them.

     This macro looks for the executable suffix used on the host

     system.  On Unix systems, this is the empty string.  On Windows

     systems, this is `.exe'.  This macro directs automake to use the

     executable suffix as appropriate when creating programs.  This

     macro does not take any arguments.

     The `AC_EXEEXT' form is new, and is part of a Cygnus patch to

     autoconf to support compiling with Visual C++.  Older programs use

     `AM_EXEEXT' instead.

     (Programs which do not use automake use neither `AC_EXEEXT' nor

     `AM_EXEEXT').

`AC_PROG_CC'

     If you are writing C code, you will normally want to use this

     macro.  It locates the C compiler to use.  It does not take any

     arguments.

     However, if this `configure.in' file is for a library which is to

     be compiled by a cross compiler which may not fully work, then you

     will not want to use `AC_PROG_CC'.  Instead, you will want to use a

     variant which does not call the macro `AC_PROG_CC_WORKS'.  Examples

     can be found in various `configure.in' files for libraries that are

     compiled with cross compilers, such as libiberty or libgloss.

     This is essentially a bug in autoconf, and there will probably be

     a better workaround at some point.

`AC_PROG_CXX'

     If you are writing C++ code, you will want to use this macro.  It

     locates the C++ compiler to use.  It does not take any arguments.

     The same cross compiler comments apply as for `AC_PROG_CC'.

`AM_PROG_LIBTOOL'

     If you want to build libraries, and you want to permit them to be

     shared, or you want to link against libraries which were built

     using libtool, then you will need this macro.  This macro is

     required in order to use libtool.

     By default, this will cause all libraries to be built as shared

     libraries.  To prevent this-to change the default-use

     `AM_DISABLE_SHARED' before `AM_PROG_LIBTOOL'.  The configure

     options `--enable-shared' and `--disable-shared' may be used to

     override the default at build time.

`AC_DEFINE(_GNU_SOURCE)'

     GNU packages should normally include this line before any other

     feature tests.  This defines the macro `_GNU_SOURCE' when

     compiling, which directs the libc header files to provide the

     standard GNU system interfaces including all GNU extensions.  If

     this macro is not defined, certain GNU extensions may not be

     available.

`AC_OUTPUT'

     This macro takes a list of file names which the configure process

     should produce.  This is normally a list of one or more `Makefile'

     files in different directories.  If your package lives entirely in

     a single directory, you would use simply `AC_OUTPUT(Makefile)'.

     If you also have, for example, a `lib' subdirectory, you would use

     `AC_OUTPUT(Makefile lib/Makefile)'.

   If you want to use locally defined macros in your `configure.in'

file, then you will need to write a `acinclude.m4' file which defines

them (if not using automake, this file is called `aclocal.m4').

Alternatively, you can put separate macros in an `m4' subdirectory, and

put `ACLOCAL_AMFLAGS = -I m4' in your `Makefile.am' file so that the

`aclocal' program will be able to find them.

   The different macro prefixes indicate which tool defines the macro.

Macros which start with `AC_' are part of autoconf.  Macros which start

with `AM_' are provided by automake or libtool.

File: configure.info,  Node: Write Makefile.am,  Next: Write acconfig.h,  Prev: Write configure.in,  Up: Getting Started

2.2 Write Makefile.am

=====================

You must write the file `Makefile.am'.  This is an automake input file,

and the automake manual describes in detail what this file should look

like.

   The automake commands in `Makefile.am' mostly look like variable

assignments in a `Makefile'.  automake recognizes special variable

names, and automatically add make rules to the output as needed.

   There will be one `Makefile.am' file for each directory in your

package.  For each directory with subdirectories, the `Makefile.am'

file should contain the line

     SUBDIRS = DIR DIR ...

   where each DIR is the name of a subdirectory.

   For each `Makefile.am', there should be a corresponding `Makefile'

in the `AC_OUTPUT' macro in `configure.in'.

   Every `Makefile.am' written at Cygnus should contain the line

     AUTOMAKE_OPTIONS = cygnus

   This puts automake into Cygnus mode.  See the automake manual for

details.

   You may to include the version number of `automake' that you are

using on the `AUTOMAKE_OPTIONS' line.  For example,

     AUTOMAKE_OPTIONS = cygnus 1.3

   This will prevent users from running an earlier version of

`automake' and perhaps getting an invalid `Makefile.in'.

   If your package builds a program, then in the directory where that

program is built you will normally want a line like

     bin_PROGRAMS = PROGRAM

   where PROGRAM is the name of the program.  You will then want a line

like

     PROGRAM_SOURCES = FILE FILE ...

   where each FILE is the name of a source file to link into the

program (e.g., `foo.c').

   If your package builds a library, and you do not want the library to

ever be built as a shared library, then in the directory where that

library is built you will normally want a line like

     lib_LIBRARIES = libNAME.a

   where `libNAME.a' is the name of the library.  You will then want a

line like

     libNAME_a_SOURCES = FILE FILE ...

   where each FILE is the name of a source file to add to the library.

   If your package builds a library, and you want to permit building the

library as a shared library, then in the directory where that library is

built you will normally want a line like

     lib_LTLIBRARIES = libNAME.la

   The use of `LTLIBRARIES', and the `.la' extension, indicate a

library to be built using libtool.  As usual, you will then want a line

like

     libNAME_la_SOURCES = FILE FILE ...

   The strings `bin' and `lib' that appear above in `bin_PROGRAMS' and

`lib_LIBRARIES' are not arbitrary.  They refer to particular

directories, which may be set by the `--bindir' and `--libdir' options

to `configure'.  If those options are not used, the default values are

based on the `--prefix' or `--exec-prefix' options to `configure'.  It

is possible to use other names if the program or library should be

installed in some other directory.

   The `Makefile.am' file may also contain almost anything that may

appear in a normal `Makefile'.  automake also supports many other

special variables, as well as conditionals.

   See the automake manual for more information.

File: configure.info,  Node: Write acconfig.h,  Next: Generate files,  Prev: Write Makefile.am,  Up: Getting Started

2.3 Write acconfig.h

====================

If you are generating a portability header file, (i.e., you are using

`AM_CONFIG_HEADER' in `configure.in'), then you will have to write a

`acconfig.h' file.  It will have to contain the following lines.

     /* Name of package.  */

     #undef PACKAGE

     /* Version of package.  */

     #undef VERSION

   This requirement is really a bug in the system, and the requirement

may be eliminated at some later date.

   The `acconfig.h' file will also similar comment and `#undef' lines

for any unusual macros in the `configure.in' file, including any macro

which appears in a `AC_DEFINE' macro.

   In particular, if you are writing a GNU package and therefore include

`AC_DEFINE(_GNU_SOURCE)' in `configure.in' as suggested above, you will

need lines like this in `acconfig.h':

     /* Enable GNU extensions.  */

     #undef _GNU_SOURCE

   Normally the `autoheader' program will inform you of any such

requirements by printing an error message when it is run.  However, if

you do anything particular odd in your `configure.in' file, you will

have to make sure that the right entries appear in `acconfig.h', since

otherwise the results of the tests may not be available in the

`config.h' file which your code will use.

   (Thee `PACKAGE' and `VERSION' lines are not required if you are not

using automake, and in that case you may not need a `acconfig.h' file

at all).

File: configure.info,  Node: Generate files,  Next: Getting Started Example,  Prev: Write acconfig.h,  Up: Getting Started

2.4 Generate files

==================

Once you have written `configure.in', `Makefile.am', `acconfig.h', and

possibly `acinclude.m4', you must use autoconf and automake programs to

produce the first versions of the generated files.  This is done by

executing the following sequence of commands.

     aclocal

     autoconf

     autoheader

     automake

   The `aclocal' and `automake' commands are part of the automake

package, and the `autoconf' and `autoheader' commands are part of the

autoconf package.

   If you are using a `m4' subdirectory for your macros, you will need

to use the `-I m4' option when you run `aclocal'.

   If you are not using the Cygnus tree, use the `-a' option when

running `automake' command in order to copy the required support files

into your source directory.

   If you are using libtool, you must build and install the libtool

package with the same `--prefix' and `--exec-prefix' options as you

used with the autoconf and automake packages.  You must do this before

running any of the above commands.  If you are not using the Cygnus

tree, you will need to run the `libtoolize' program to copy the libtool

support files into your directory.

   Once you have managed to run these commands without getting any

errors, you should create a new empty directory, and run the `configure'

script which will have been created by `autoconf' with the

`--enable-maintainer-mode' option.  This will give you a set of

Makefiles which will include rules to automatically rebuild all the

generated files.

   After doing that, whenever you have changed some of the input files

and want to regenerated the other files, go to your object directory

and run `make'.  Doing this is more reliable than trying to rebuild the

files manually, because there are complex order dependencies and it is

easy to forget something.

File: configure.info,  Node: Getting Started Example,  Prev: Generate files,  Up: Getting Started

2.5 Example

===========

Let's consider a trivial example.

   Suppose we want to write a simple version of `touch'.  Our program,

which we will call `poke', will take a single file name argument, and

use the `utime' system call to set the modification and access times of

the file to the current time.  We want this program to be highly

portable.

   We'll first see what this looks like without using autoconf and

automake, and then see what it looks like with them.

* Menu:

* Getting Started Example 1::           First Try.

* Getting Started Example 2::           Second Try.

* Getting Started Example 3::           Third Try.

* Generate Files in Example::           Generate Files.

File: configure.info,  Node: Getting Started Example 1,  Next: Getting Started Example 2,  Up: Getting Started Example

2.5.1 First Try

---------------

Here is our first try at `poke.c'.  Note that we've written it without

ANSI/ISO C prototypes, since we want it to be highly portable.

     #include 

     #include 

     #include 

     #include 

     int

     main (argc, argv)

          int argc;

          char **argv;

     {

       if (argc != 2)

         {

           fprintf (stderr, "Usage: poke file\n");

           exit (1);

         }

       if (utime (argv[1], NULL) < 0)

         {

           perror ("utime");

           exit (1);

         }

       exit (0);

     }

   We also write a simple `Makefile'.

     CC = gcc

     CFLAGS = -g -O2

     all: poke

     poke: poke.o

        $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o

   So far, so good.

   Unfortunately, there are a few problems.

   On older Unix systems derived from BSD 4.3, the `utime' system call

does not accept a second argument of `NULL'.  On those systems, we need

to pass a pointer to `struct utimbuf' structure.  Unfortunately, even

older systems don't define that structure; on those systems, we need to

pass an array of two `long' values.

   The header file `stdlib.h' was invented by ANSI C, and older systems

don't have a copy.  We included it above to get a declaration of `exit'.

   We can find some of these portability problems by running

`autoscan', which will create a `configure.scan' file which we can use

as a prototype for our `configure.in' file.  I won't show the output,

but it will notice the potential problems with `utime' and `stdlib.h'.

   In our `Makefile', we don't provide any way to install the program.

This doesn't matter much for such a simple example, but a real program

will need an `install' target.  For that matter, we will also want a

`clean' target.

File: configure.info,  Node: Getting Started Example 2,  Next: Getting Started Example 3,  Prev: Getting Started Example 1,  Up: Getting Started Example

2.5.2 Second Try

----------------

Here is our second try at this program.

   We modify `poke.c' to use preprocessor macros to control what

features are available.  (I've cheated a bit by using the same macro

names which autoconf will use).

     #include 

     #ifdef STDC_HEADERS

     #include 

     #endif

     #include 

     #ifdef HAVE_UTIME_H

     #include 

     #endif

     #ifndef HAVE_UTIME_NULL

     #include 

     #ifndef HAVE_STRUCT_UTIMBUF

     struct utimbuf

     {

       long actime;

       long modtime;

     };

     #endif

     static int

     utime_now (file)

          char *file;

     {

       struct utimbuf now;

       now.actime = now.modtime = time (NULL);

       return utime (file, &now);

     }

     #define utime(f, p) utime_now (f)

     #endif /* HAVE_UTIME_NULL  */

     int

     main (argc, argv)

          int argc;

          char **argv;

     {

       if (argc != 2)

         {

           fprintf (stderr, "Usage: poke file\n");

           exit (1);

         }

       if (utime (argv[1], NULL) < 0)

         {

           perror ("utime");

           exit (1);

         }

       exit (0);

     }

   Here is the associated `Makefile'.  We've added support for the

preprocessor flags we use.  We've also added `install' and `clean'

targets.

     # Set this to your installation directory.

     bindir = /usr/local/bin

     # Uncomment this if you have the standard ANSI/ISO C header files.

     # STDC_HDRS = -DSTDC_HEADERS

     # Uncomment this if you have utime.h.

     # UTIME_H = -DHAVE_UTIME_H

     # Uncomment this if utime (FILE, NULL) works on your system.

     # UTIME_NULL = -DHAVE_UTIME_NULL

     # Uncomment this if struct utimbuf is defined in utime.h.

     # UTIMBUF = -DHAVE_STRUCT_UTIMBUF

     CC = gcc

     CFLAGS = -g -O2

     ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS)

     all: poke

     poke: poke.o

        $(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o

     .c.o:

        $(CC) -c $(ALL_CFLAGS) poke.c

     install: poke

        cp poke $(bindir)/poke

     clean:

        rm poke poke.o

   Some problems with this approach should be clear.

   Users who want to compile poke will have to know how `utime' works

on their systems, so that they can uncomment the `Makefile' correctly.

   The installation is done using `cp', but many systems have an

`install' program which may be used, and which supports optional

features such as stripping debugging information out of the installed

binary.

   The use of `Makefile' variables like `CC', `CFLAGS' and `LDFLAGS'

follows the requirements of the GNU standards.  This is convenient for

all packages, since it reduces surprises for users.  However, it is

easy to get the details wrong, and wind up with a slightly nonstandard

distribution.

File: configure.info,  Node: Getting Started Example 3,  Next: Generate Files in Example,  Prev: Getting Started Example 2,  Up: Getting Started Example

2.5.3 Third Try

---------------

For our third try at this program, we will write a `configure.in'

script to discover the configuration features on the host system, rather

than requiring the user to edit the `Makefile'.  We will also write a

`Makefile.am' rather than a `Makefile'.

   The only change to `poke.c' is to add a line at the start of the

file:

     #include "config.h"

   The new `configure.in' file is as follows.

     AC_INIT(poke.c)

     AM_INIT_AUTOMAKE(poke, 1.0)

     AM_CONFIG_HEADER(config.h:config.in)

     AC_PROG_CC

     AC_HEADER_STDC

     AC_CHECK_HEADERS(utime.h)

     AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF))

     AC_FUNC_UTIME_NULL

     AC_OUTPUT(Makefile)

   The first four macros in this file, and the last one, were described

above; see *Note Write configure.in::.  If we omit these macros, then

when we run `automake' we will get a reminder that we need them.

   The other macros are standard autoconf macros.

`AC_HEADER_STDC'

     Check for standard C headers.

`AC_CHECK_HEADERS'

     Check whether a particular header file exists.

`AC_EGREP_HEADER'

     Check for a particular string in a particular header file, in this

     case checking for `utimbuf' in `utime.h'.

`AC_FUNC_UTIME_NULL'

     Check whether `utime' accepts a NULL second argument to set the

     file change time to the current time.

   See the autoconf manual for a more complete description.

   The new `Makefile.am' file is as follows.  Note how simple this is

compared to our earlier `Makefile'.

     bin_PROGRAMS = poke

     poke_SOURCES = poke.c

   This means that we should build a single program name `poke'.  It

should be installed in the binary directory, which we called `bindir'

earlier.  The program `poke' is built from the source file `poke.c'.

   We must also write a `acconfig.h' file.  Besides `PACKAGE' and

`VERSION', which must be mentioned for all packages which use automake,

we must include `HAVE_STRUCT_UTIMBUF', since we mentioned it in an

`AC_DEFINE'.

     /* Name of package.  */

     #undef PACKAGE

     /* Version of package.  */

     #undef VERSION

     /* Whether utime.h defines struct utimbuf.  */

     #undef HAVE_STRUCT_UTIMBUF

File: configure.info,  Node: Generate Files in Example,  Prev: Getting Started Example 3,  Up: Getting Started Example

2.5.4 Generate Files

--------------------

We must now generate the other files, using the following commands.

     aclocal

     autoconf

     autoheader

     automake

   When we run `autoheader', it will remind us of any macros we forgot

to add to `acconfig.h'.

   When we run `automake', it will want to add some files to our

distribution.  It will add them automatically if we use the

`--add-missing' option.

   By default, `automake' will run in GNU mode, which means that it

will want us to create certain additional files; as of this writing, it

will want `NEWS', `README', `AUTHORS', and `ChangeLog', all of which

are files which should appear in a standard GNU distribution.  We can

either add those files, or run `automake' with the `--foreign' option.

   Running these tools will generate the following files, all of which

are described in the next chapter.

   * `aclocal.m4'

   * `configure'