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
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.
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
libtoolizeis used to install them or not.
autoconf expands the
m4 macros in `configure.in', perhaps using macro definitions from `aclocal.m4', to generate the
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.
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
The final tool to be run is
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.