GNU Tool

Makefile:-

Why Use a Makefile?

In any project you can have any number of source files. Now imagine having to recompile even the simplest of programs consisting of two source files, binarytree.c and mainprog.c. You will need to type the following command:

gcc -o outprogname binarytree.c mainprog.c

Now, since that mainprog.c files takes ages to compile, you don't want to recompile it everytime, the same goes for the binarytree.c file. Now imagine you had a hundred source files (think big, and then some more).

A Makefile makes this simple by allowing us to specify rules (consisting of dependencies and commands) to build our project.

---

A Simple Makefile Example

The following is a very simple, but complete Makefile:

outprogname : binarytree.o mainprog.o         gcc -o outprogname binarytree.o mainprog.o  binarytree.o : binarytree.c         gcc -c binarytree.c  mainprog.o : mainprog.c         gcc -c mainprog.c

Please note that the indented lines begins with a tab character.

In the case where both files needs to be compiled, make will issue three commands - yes this can be wasteful – namely & also we can put all object file in to Makefile and compile by using make command

#make

aclocal

The aclocal program creates the file `aclocal.m4' by combining stock installed macros, user defined macros and the contents of `acinclude.m4' to define all of the macros required by `configure.in' in a single file. aclocal was created as a fix for some missing functionality in Autoconf, and as such we consider it a wart. In due course aclocal itself will disappear, and Autoconf will perform the same function unaided.

autoheader

autoheader runs m4 over `configure.in', but with key macros defined differently than when autoconf is executed, such that suitable cpp definitions are output to `config.h.in'.

automake and libtoolize

automake will call libtoolize to generate some extra files if the macro `AC_PROG_LIBTOOL' is used in `configure.in'. If it is not present then automake will install `config.guess' and `config.sub' by itself.

libtoolize can also be run manually if desired; automake will only run libtoolize automatically if `ltmain.sh' and `ltconfig' are missing.

The versions of `config.guess' and `config.sub' installed differ between releases of Automake and Libtool, and might be different depending on whether libtoolize is used to install them or not.

autoconf

autoconf expands the m4 macros in `configure.in', perhaps using macro definitions from `aclocal.m4', to generate the configure script.

configure

The purpose of the preceding processes was to create the input files necessary for configure to run correctly. You would ship your project with the generated script and the files in columns, other input and processes (except `config.cache'), but configure is designed to be run by the person installing your package. Naturally, you will run it too while you develop your project, but the files it produces are specific to your development machine, and are not shipped with your package -- the person installing it later will run configure and generate output files specific to their own machine.

Running the configure script on the build host executes the various tests originally specified by the `configure.in' file, and then creates another script, `config.status'. This new script generates the `config.h' header file from `config.h.in', and `Makefile's from the named `Makefile.in's. Once `config.status' has been created, it can be executed by itself to regenerate files without rerunning all the tests. Additionally, if `AC_PROG_LIBTOOL' was used, then ltconfig is used to generate a libtool script.

make

The final tool to be run is make. Like configure, it is designed to execute on the build host. make will use the rules in the generated `Makefile' to compile the project sources with the aid of various other scripts generated earlier on.