Keywords: make+, make, automake, autoconf, rpm, deb, dpkg, package

Chapter 3. Compiling a package which has been converted to use make+
Prev |  | Next

## Chapter 3. Compiling a package which has been converted to use make+

If you have been given an application which has been converted to use make+ already and you just want to compile it, then you're likely to read the generic `INSTALL` file and follow those instructions. This chapter explains the steps needed to compile an application, but also covers what's happening "behind the scenes" at each step.

The basic steps for compiling a make+-enabled application are:

- Configure the application using ./configure

- Compile the application by typing make+

- Run any supplied tests by typing make+ test

- Install the application (as root) with make+ install

But what is actually happening at each step?

## Configuration

The configuration step sets up the installation paths and then examines the system looking for required and optional programs and libraries.

We can imagine a fictional C debugging library. This requires the GNU bfd library to read executables. In addition, if the Linux-specific `backtrace` function is present in libc, then our fictional library can present more readable stack traces when a program crashes. The configure step for this library would first examine the system looking for the GNU bfd library. If not found, it would stop with an error, telling the user that they must install this library. It would then look for the `backtrace` function, but if this function was not present, it would not be a fatal error.

During the configuration step is also the point where we specify where we want to install the program. Normally users will be interested in setting the `prefix` variable which controls the overall location of the installation. It defaults to `/usr/local` which causes most files to be installed in subdirectories of this directory, but some users will want to change the prefix, commonly to `/usr`.

The result of the configuration step is three files in the build directory:

`config.h`

  A C/C++ header file describing the capabilities of the system. For our imaginary debugging library the C header file might look like this:

      /* Generated automatically by make+. */

      #ifndef MP_CONFIG_H
      #define MP_CONFIG_H

      #define PACKAGE "foo"
      #define VERSION "0.0.1"
      #define HAVE_LIBBFD 1
      #define HAVE_BACKTRACE 1

      #endif /* MP_CONFIG_H */

  Happily we can see that this platform has both the required GNU bfd and the optional `backtrace` function.

`config.mk`

  This file is a `Makefile` fragment which is included directly the next time that make+ runs (ie. it is included when we do the compile, test and install steps).

  The purpose of this file is threefold. Firstly to define the `LIBS` variable, which is built on the fly as a result of detecting required and optional libraries. Secondly to save the installation paths (the `prefix` and related paths). Thirdly to save the results of the configuration tests in a way which is accessible to the `Makefile+`.

  An extract from the `config.mk` file for our fictional debugging library:

      prefix     = /usr
      bindir     = /usr/bin
      sbindir    = /usr/sbin
      libexecdir = /usr/libexec
        #
        # many lines omitted
        #
      LIBS       = -lbfd

      HAVE_LIBBFD = 1
      HAVE_BACKTRACE = 1

`config.log`

  This file logs every command issued during the configuration step, and is very useful for debugging problems.

make+-enabled applications come with a simple configure script. This is not just a convenience (users are used to typing ./configure --prefix=/usr). It also removes the old `config.mk` file before running make+ configure, which is essential to ensure that any previous installation paths do not accidentally take precedence.

Prev | Up | Next
Chapter 2. make+ theory of operation | Home | Compiling and testing