Header Files in Multiple Directories: Best Practices

Question

I'm a C Newb

I write lots of code in dynamic languages (javascript, python, haskell, etc.), but I'm now learning C for graduate school and I have no idea what I'm doing.

The Problem

Originally I was building all my source in one directory using a makefile, which has worked rather well. However, my project is growing and I would like to split the source into multiple directories (unit tests, utils, core, etc.). For example, my directory tree might look like the following:

.
|-- src
|   |-- foo.c
|   |-- foo.h
|   `-- main.c
`-- test
    `-- test_foo.c

test/test_foo.c uses both src/foo.c and src/foo.h. Using makefiles, what is the best/standard way to build this? Preferably, there would be one rule for building the project and one for building the tests.

Note

I know that there are other ways of doing this, including autoconf and other automatic solutions. However, I would like to understand what is happening and be able to write the makefiles from scratch despite its possible impracticality.

Any guidance or tips would be appreciated. Thanks!

[Edit]

So the three solutions given so far are as follows:

• Place globally used header files in a parallel include directory
• use the path in the #include satement as in #include "../src/foo.h"
• use the -I switch to inform the compiler of include locations

So far I like the -I switch solution because it doesn't involve changing source code when directory structure changes.

Answer 1

A common way of doing this is for header files used by a single C file to be named the same as that C file and in the same directory, and for header files used by many C files (especially those used by the whole project) to be in a directory include that is parallel to the C source directory.

Answer 2

Your test file should just include the header files directly using relative paths, like this:

#include "../src/foo.h"

Answer 3

For test_foo.c you simply need to tell the compiler where the header files can be found. E.g.

gcc -I../src -c test_foo.c

Then the compiler will also look into this directory to find the header files. In test_foo.c you write then:

#include "foo.h"

EDIT: To link against foo.c, actually against foo.o, you need to mention it in the object file list. I assume you have already the object files, then do after that:

gcc test_foo.o ../src/foo.o -o test

Answer 4

I also rarely use the GNU autotools. Instead, I'll put a single hand-crafted makefile in the root directory.

To get all headers in the source directory, use something like this:

get_headers = $(wildcard $(1)/*.h)
headers := $(call get_headers,src)

Then, you can use the following to make the object-files in the test directory depend on these headers:

test/%.o : test/%.c $(headers)
    gcc -std=c99 -pedantic -Wall -Wextra -Werror $(flags) -Isrc -g -c -o $@ $<

As you can see, I'm no fan of built-in directives. Also note the -I switch.

Getting a list of object-files for a directory is slightly more complicated:

get_objects = $(patsubst %.c,%.o,$(wildcard $(1)/*.c))
test_objects = $(call get_objects,test)

The following rule would make the objects for your tests:

test : $(test_objects)

The test rule shouldn't just make the object files, but the executables. How to write the rule depends on the structure of your tests: Eg you could create an executable for each .c file or just a single one which tests all.

Answer 5

You can take a look at a Makefile I'm currently using. Its not perfect, but shows a few interesting things:

• I set up a list of all subdirs in one big symbol, $SUBDIRS. This makes it easy to pass them as include paths and simplifies cleaning targets
• I'm using gcc to keep track of dependencies (especially headers)
• Sources are categorized so its easy to set up targets to build many individual programs

The Makefile is by NO means perfect, the project that its building is very alpha. When the project settles down, I'll go through and really properize things in the Makefile. However, the example should show you what you want to know.

Note, the link points to my current (tip) revision of that file, I did this so if I change it in the future the link on SO is still valid in the context of this answer.

EDIT:

I'm using autoconf to expand the @symbols@ in some parts of the Makefile, don't let that confuse you.