Chapter 2. Preparation

If you haven't already done so, download the crpcut sources from http://downloads.sourceforge.net/crpcut/crpcut-1.9.4.tar.bz2. The directory you unpack the sources to will be called <source-dir> in the rest of this guide. You may also want to download the documentation from http://downloads.sourceforge.net/crpcut/crpcut-doc-1.9.4.tar.bz2.

crpcut defaults to install under /usr/{lib,include,share}. If you want to use another destination, add the command line parameter -DCMAKE_INSTALL_PREFIX=<path> to the CMake line. The directory you want to install to will be called <prefix-dir> in the rest of this guide.

You can also fine tune the name of the directory where the libraries are stored. Often seen variants are lib, lib32 and lib64. By default the directory name is lib64 on 64-bit systems, and just lib on 32-bit systems. You can choose your suffix with -DLIB_SUFFIX=name. If name is the empty string, lib will be used also on 32-bit systems. If you want something completely different, use -DLIBRARY_OUTPUT_PATH=name instead. Then name will be the complete name of the directory, and the suffix variable will be ignored.

You are highly encouraged to build crpcut on a machine that has valgrind installed.

If <valgrind/valgrind.h> can be found when running CMake, crpcut will add instrumentation instructions for valgrind. These instrumentation instructions are no-ops when running natively, or on a machine that doesn't have valgrind, but can help immensely in finding memory access errors when running tests under valgrind.

If you build crpcut for a binary distribution, you should definitely build on a machine with valgrind.

For environments in which the backtrace() function is available, crpcut can display a stack backtrace when heap violations are discovered (where the heap objects was allocated and, when applicable, where it was last changed.) Should you not want this, add the command line parameter -DUSE_BACKTRACE=no to the CMake line.

If you want to use another compiler than the default for CMake, or if CMake is unable to find one, prefix the CMake line with CXX="<compilername>", for example:

     bash > CXX="g++-4.6.0" cmake /tmp/download/crpcut

Compiling crpcut with debugging enabled may make it easier to debug your tests, or analyse core dumps, since the tests are started from crpcut

To enable debug builds, add the command line parameter -DCMAKE_BUILD_TYPE="debug" to the CMake line when building.

By default crpcut builds as a shared library. Should you want to build a static library (libcrpcut.a) instead, add the command line parameter -DBUILD_SHARED_LIBS=false to the CMake line when building.

Running a self test after build is a good way to verify that crpcut functions correctly. To run a self test, you need ruby, and you must enable core-dumps as "core" in the current working directory (since the self test verifies that certain crashes do dump core as expected.) If you run Linux, ensure that /proc/sys/kernel/core_pattern contains only the word "core".

If you have google-mock installed, you can add a few test cases that verify google-mock interaction with crpcut by adding the command line parameter -DWITH_GOOGLE_MOCK=yes to the CMake. Should CMake be unable to find your google-mock installation, you can help it by adding the command line parameter -DGOOGLE_MOCK_DIR=<path-to-google-mock>.

	Caution
	If you run the self test on a very slow computer, like a net book, timeout tests are likely to fail.

You are not encouraged to build the documentation yourself, but rather download it from sourceforge via http://downloads.sourceforge.net/crpcut/crpcut-doc-1.9.4.tar.bz2. However, should you choose to build it anyway, you will need

You will also need to add -DWITH_HTML_DOCS=yes to the CMake command line.