How to Build Software With Make
Published on 2023-03-27 22:35:00+02:00
To compile an executable from a single C source file we need just one compiler invocation in our shell:
$ cc myprogram.c -o myprogram
As we expand our projects they naturally become harder to build. If not due to dependencies then due to pure
repetitiveness of the task. Build systems are a response to
that and GNU Make is one of them. GNU Make is part of a larger family
of programs that usually share the make(1) (or similar, e.g., nmake, mk). Although timeline doesn't necessarily
agree, we can say that make is defined in
Principles of Make are straight-forward: as a user we define a set of rules that consist of targets, dependencies and
commands. Targets are usually filenames that describe what rule is expected to produce. Dependencies are names of other
targets or source files. That's it. Later this concept is expanded upon to reduce the amount of lines we need to write.
When we build native software we are mainly interested in:
- Executables (e.g., ELF, PE *.exe)
- Static libraries (e.g., *.a, *.lib)
- Dynamic/shared libraries (e.g., *.so, *.dll)
Since make live close to the compiler we will be also interested in object files (e.g., *.o, *.obj).
How to Build Executables With Make
Make helps us to reduce number of characters we need to type in terminal and lines we need to put to setup the
build. In fact, the simplest case of one source file to one executable, like the one I showed above, does not need any
preparation at all:
$ make myprogram
cc myprogram.c -o myprogram
First thing that we should observe is that make nonchalantly prints the commands it executes to build stuff
for us. I'll keep them visible in samples so it's hopefully more clear what's happening.
We invoke make directly with a name of the target we intend to build. Remember: targets are usually filenames
that are expected to be produced by a rule. Based on the target name and built-in rules make guesses what to do
to get myprogram. It finds myprogram.c in the working directory and selects an appropriate rule.
Yet, we still need to type the target name each time we want to build it. We can avoid it by creating a file called
Makefile in the project directory. This is the file containing all build rules and other helpful definitions. If
make is ran without any targets then the first target found in Makefile is used. Consider Makefile:
Let's try it:
cc myprogram.c -o myprogram
Selects the first and the only target as intended.
There are traditional targets
that users of our makefiles may expect. A less bare-bone makefile would look like this:
rm -f myprogram
.PHONY: all clean
Now, someone can run following to ensure that a clean build is made:
$ make clean all
rm -f myprogram
cc myprogram.c -o myprogram
Let's note that we can specify multiple targets in the command line. They will be build in order.
all: myprogram - this notation specifies that target all depends on myprogram. We
can specify multiple dependencies if needed. All dependencies will be built and once they are done the dependant target
will be processed.
.PHONY is a special target that is used to mark targets that are not expected to produce files. We are
not expecting all or clean files to be present at any stage. Instead we can imagine these as tasks or
actions. Other such targets would be for example install, uninstall or dist.
How to Build Object Files With Make
Usually, we won't implement our projects inside a single source file. We want to split logical parts of the software
into several files. Consider greeting.h:
With accompanying greeting.c:
And our program that uses them, let's stay with myprogram.c:
As simple as it gets while it still illustrates the problem.
When we build our program from a single source the compiler does two things: compiles and links. Now we want to do
these separately. An intermediate result of compilation is an object file. On Linux and Unix platforms they usually use
*.o extension. We can instruct make to use them by adding new rules to our existing makefile:
myprogram: myprogram.o greeting.o
First we declare that in order to build myprogram two object files are needed. Then we define some additional
relationships between the object files and the only header file that we have.
Note that we did not specify explicitly dependency between the object files and the respective source files.
Technically we could also skip the relationship between myprogram and myprogram.o and make would
still figure it out. This is a matter of what we want to declare explicitly, how lazy we are at the time of writing and
how permissive are the built-in rules that we use.
Let's try it out:
cc -c -o myprogram.o myprogram.c
cc -c -o greeting.o greeting.c
cc myprogram.o greeting.o -o myprogram
How to Build Static Libraries With Make
The best part here is that we're pretty much already set. Static libraries are archives containing object files. They
are created and updates using ar(1). There are built-in rules available for them, too, but with one additional
gimmick. They use archive targets that look like this:
myprogram: myprogram.o libgreeting.a
We replaced greeting.o prerequisite with libgreeting.a which is defined line below. Dependencies of the
library target are expressed as
How to Build Shared Libraries With Make
Shared/dynamic libraries are different. The process of building them with make is similar to executables, but
we want to modify compilation and linking options, and write our own command:
$(LD) -shared $(LDLIBS) $(LDFLAGS) $^ -o $@
First two lines are variable definitions (called "macros" in POSIX). We set CFLAGS - C compiler flags - to
-fPIC to enable position-independent
code, which is needed when compiling code for shared libraries that are expected to work nicely on Linux. Then, we
set LDFLAGS - linker flags - to
-shared which (put simply) tells the linker to build a shared
Now let's analyse linker command itself. Starting with
$(LD); it's substituted with the linker
executable. We already know
$(LDLIBS) sounds quite similar. This one is
intended to store all external libraries that linker should use. Finally, we have two
automatic variables also known
$^ (substituted with all dependencies) and
$@ (substituted with target name). Note
$^ is not part of POSIX.
When we finally run make we can observe predicted commands:
cc -fPIC -c -o greeting.o greeting.c
ld -shared greeting.o -o libgreeting.so
$(LD) is provided by default by make.
In some cases, we may want to invoke the linker via the compiler to have all defaults implicitly defined. For example
for C++ we would replace
$(CXX) to imply e.g.,
How to Build Against External Libraries With Make
This one starts to be tricky. The simple case where we use libraries installed in /usr or /usr/local is
exactly that - simple. All we need to do is put linker options in a variable (macro) that we have already seen:
Since managing these manually easily becomes a problem there are tools that can generate list of these options for
us. One of them is pkgconfig(1). In most make implementations we can use backticks to run command and use
CFLAGS=`pkg-config --cflags lua`
LDLIBS=`pkg-config --libs lua`
This will link Lua and make its headers available.
This is only a beginning. I hope it's a good overview, but the true journey awaits. This is but a dump of information
and playing around with make sounds like a reasonable next step. Because of its simple design make is not
limited to C, C++, yacc/bison or Fortran. I use it for most small weekend projects I do, be it RST to HTML generation or
image rendering. Anything that can be described as processing from one file to another (or generation from thin air) is
good enough to be put into a makefile.
Next step after playing around some is diving deeper into automatic variables and
pattern rules. I'd recommend to
skip over inference