Including cpputest in makefile for project

Question

I want to include cpputest in my project's source tree as a git submodule, but I am not terribly familiar with autotools.

I have been looking at this page as a guide

I've created the following Makefile, cpputest is in a sub-directory beneath it:

CPPUTEST_BUILD_DIR := cpputest/cpputest_build

CPPUTEST_LIBS :=                           \
    $(CPPUTEST_BUILD_DIR)/libCppUTest.a    \
    $(CPPUTEST_BUILD_DIR)/libCppUTestExt.a

CPPUTEST_TESTS :=                          \
    $(CPPUTEST_BUILD_DIR)/CppUTestTests    \
    $(CPPUTEST_BUILD_DIR)/CppUTestExtTests

cpputest:                           \
    cpputest/configure              \
    $(CPPUTEST_BUILD_DIR)/Makefile  \
    $(CPPUTEST_LIBS)                \
    $(CPPUTEST_TESTS)

cpputest/configure: cpputest/configure.ac cpputest/autogen.sh
    cd cpputest && ./autogen.sh

cpputest/cpputest_build/Makefile: cpputest/configure
    cd $(CPPUTEST_BUILD_DIR) && ../configure

$(CPPUTEST_LIBS): $(CPPUTEST_BUILD_DIR)/Makefile
    cd $(CPPUTEST_BUILD_DIR) && make

$(CPPUTEST_TESTS): $(CPPUTEST_LIBS)
    cd $(CPPUTEST_BUILD_DIR) && make tdd

Running this makefile does what I want but I am not sure how robust the dependencies are. Is there anything else I should consider adding to this, besides a clean rule?

---

Here is my final Makefile after John Bollinger's answer.

It is located in the root of the CppUTest directory.

# This makefile will generate a platform specific makefile, build CppUTest
# library outputs, and build and run tests on CppUTest.
BUILD_DIR := cpputest_build

LIBS := $(BUILD_DIR)/lib/libCppUTest.a $(BUILD_DIR)/lib/libCppUTestExt.a

TESTS := $(BUILD_DIR)/CppUTestTests $(BUILD_DIR)/CppUTestExtTests

# All builds both libraries, to build and run all of the tests for CppUTest use
# the phony target run_tests.
all: $(LIBS)

.PHONY: all run_tests clean FORCE

# The Makefile rule depends on the "configure" shell script existing. If
# CppUTest is updated from upstream or configure doesn't exist then run
# autogen.sh or uncomment the rule below. All of the outputs autogen.sh should
# be tracked in the develop branch.
#
#configure: configure.ac autogen.sh
#   ./autogen.sh

$(BUILD_DIR)/Makefile: configure
    mkdir -p $(BUILD_DIR) && cd $(BUILD_DIR) && ../configure

$(LIBS) : $(BUILD_DIR)/Makefile FORCE
    cd $(BUILD_DIR) && make $(subst $(BUILD_DIR)/,,$@)

$(TESTS) : $(BUILD_DIR)/Makefile FORCE
    cd $(BUILD_DIR) && make $(@F)

run_tests: $(TESTS)
    for test in $(TESTS); do $$test -c || exit 1; done


clean:
    rm -rf $(BUILD_DIR)

Answer 1

Is there anything else I should consider adding to this, besides a clean rule?

TL;DR: You should pre-run ccptest's autogen.sh script, and include all the resulting files in your distribution along with all the rest. You could then consider also omitting the rule for building cpputest/configure (I would indeed omit it, myself).

---

Cpputest is apparently following a recent trend of omitting Autotools-generated files from source control. That makes sense on the surface, because those files can indeed be generated from others that are available from source control. It's fine from the perspective of a source control system being a project maintenance and development tool. It is not fine, however, with respect to source control used as a distribution tool.

One of the design goals of the Autotools is that they themselves are needed only by project maintainers. Running them is not intended to be part of a routine build process, such as someone who just wants to build and run the software would employ. Accordingly, distribution packages prepared by Autotools build systems themselves include all the needed bits to make that possible: the configure script, supporting utility scripts, Makefile.in files, and sometimes a few other miscellaneous files. This is the intended form for distribution.

This being the case, there is less compatibility pressure on the Autotools than there is on many projects, and indeed that manifests in weaker compatibility between different AT versions. If you build the build system with a different version of AT than the project maintainers themselves do, then you may encounter errors. You definitely will get a build system with some amount of difference from the one the maintainers use. Often the result will still build the project without issue, but sometimes not. So do yourself a favor and sidestep that issue.

Running this makefile does what I want but I am not sure how robust the dependencies are.

The makefile itself looks pretty good to me. The main things I see to criticize are

• the rule for cpputest/cpputest_build/Makefile spells out the directory part literally instead of using the $(CPPUTEST_BUILD_DIR) variable.

• the cpputest target's prerequisite list should not include either cpputest/configure or $(CPPUTEST_BUILD_DIR)/Makefile. That these are required for the build process is incidental, and is already addressed by those artifacts being listed as prerequisites of the targets that depend directly on them. As a matter of style, maintainability, and general good practice, make rules should list only targets' direct prerequisites.

Inasmuch as I am recommending that you distribute the build system components instead of making everyone rebuild them, however, I would also remove the rule for building cpputest/configure. If you follow my advice then you'll distribute a pre-built one, so users won't need to build it. Omitting the rule and pulling cpputest/configure from those prerequisite lists where it appears will eliminate a minor risk of everything falling over in the event that timestamps get scrambled, as can sometimes happen when a source tree gets copied.

As for a clean rule, since you're doing cpputest configuration under control of the top-level make, the corresponding way to clean would be to cd $(CPPUTEST_BUILD_DIR); make distclean. However, since you're performing an out-of-source build, you also have the alternative of just recursively removing the build directory. Note, however, that if you persist with running autogen.sh as part of your build process then the generated files are not restricted to the build directory. In that case, the corresponding clean would probably involve make maintainer-clean.