Main Content

Make - automating the commands for building and installing

Archive - Originally posted on "The Horse's Mouth" - 2010-11-16 04:10:41 - Graham Ellis

Coding projects (and their open source distributions) require build scripts - files of commands that convert the source code into executable programs, that install the various resultant files into place, and that can clean up the build area for a fresh build or for redistribution. The make system - with makefiles - is the usual way to do this (in the case of C and C++ programs anyway - in the Java world, Ant is the more usual approach).

How do build systems work?

You specify a target (the file you want to build), some dependencies (the files which - if changed - necessitate a rebuild) and a set of rules for making the target. You build a whole series of sets of targets, dependencies and rules with the target of one set of rules - the name of the output file from a set of rules - being amongst the dependencies (inputs) at the next level. Then when you say "make" the first target in your Makefile, and anything it depends on too, is rebuilt.

Make is very clever in that it examines the whole build tree before it does anything, so that rules are followed all the way back to see which need to be run, the they're run all the way forward so that they happen (a) only if necessary and (b) in the right order. File timestamps are used to check what has changed, so if you want to force one of the sets of rules to be run, you can simply touch one of the dependencies and rerun make.

There is a commented example of a Makefile - showing and describing its format - [here].

It's the nature of a compile and build operation in a language such as C or C++ that a very similar set of operations will be performed on a whole series of files - for example, there may be dozens of .cpp files to be compiled into .o files, all with the same compiler and compile time options. So to make your makefile shorter and easier to maintain for consistency, you can specify make variables and make default rules. There's a further example that shows these features [here] - again that's commented and kept fairly short and straight forward to help the newcomer.



When you download an open source distribution, please READ THE INSTALL GUIDE before you build and install it. You'll find that in a file called INSTALL or something similar in the unpacked distribution. And you'll often find the procedure goes like this:

./configure --with-summat --enable-summat-else --etc
make
make test
make install

With C and C++ programs which run across different flavors of operating systems, your makefile needs to be updated to ensure that the resulting executables make good use of what the OS offers, and that the build doesn't attempt to use facilities that aren't available. You also need the ability to choose options to build in and out, and perhaps to specify target directory paths. The ./configure script / program takes your various requests, analysis and looks round the system on which you're doing the build. It advises you of any dependencies that are missing (i.e. other bits of software you'll need to install files) and outputs a Makefile.

The make operation does the actual compiles and builds; that will usually include other subsidiary targets to unpack and prepare documentation directories, configuration files for the application itself when run, etc.

make test will put the newly build application through a whole series of checks to ensure that the output is 100% fine - this is designed to catch anything that hasn't worked as it should in the build process, and may also serve to give you an early alert of facilities that are missing or non-functional on your particular operating system / configuration. The output of make test is a report, so if you're repeating the same build across a large number of systems you might consider skipping it; on occasions that we're rebuilding a series of systems, we sometimes do - but then we're building for a week's training and not for systems that are going to sit in an exposed production environment for perhaps years.

The final step - make install - copies the output of make from the staging / development area where make wrote its output to the production area. You'll usually need to be logged in as the administrator - for this step only! - and you should remember to get yourself a full root environment. In other words - do not use su without any options; use su - (a lone minus option), even though the latter moves you to root's home directory and having to cd back to your build area.

P.S. Before you make install you should check that any prior versions that you're going to overwrite aren't actually running. Also consider using a fresh parallel install directory as that will give you the ability to rollback if you find the need.