Compiling and Testing¶
We will go through some steps to build dependencies, compile and test OCLint in this document. In general, if you have followed the codebase structure as described in this document, we have scripts to gather all required steps and run them in order to facilitate the entire process.
if you need a release version OCLint binary for production use, please read Building OCLint instead.
This document presumes your current working directory is
We could build LLVM/Clang in debug mode with assertions by
Debug mode binaries contain additional data to aid debugging, but lowers program performances. It’s recommended to build Clang in debug mode when we work on the analysis engine, metrics, and rules. These debug information may help a lot in some circumstances.
On the other side, if our work is related to violations, reporters, and surrounding submodules, we can still use debug mode, and we can also choose release mode that enables optimizations for better performance. To build LLVM/Clang in release mode, append
release to the script as
./clang build -release
It takes a while to build LLVM/Clang (probably much longer than a cup of coffee time). By default, this script builds the code by simultaneously using all the CPU resources. But this can be changed by explicitly specifying number of concurrent processes for the compilation, like
./clang build -j <num>
The LLVM/Clang build can be found at
oclint/build/llvm directory, and its installation is located at
We provide a script to build countly-cpp without hassle. Again, you only need this if you build OCLint with analytics enabled.
Building Google C++ Testing and Mocking Frameworks is easy:
Compiling and Testing OCLint¶
OCLint uses CMake as build system. We can find CMakeLists.txt in each module and its include sub-folders.
test script would compiles and tests OCLint core module, metrics module, rules module, and reporters module. With module name given, the script tests only for the particular module, otherwise, it tries to test all modules. Core module and metrics module can be compiled independently. However, rules module depends on both core and metrics modules, and reporters module depends on core module. When
test script works with all modules, the required sequence is automatically enforced.
test script has a
-clean option to remove old build intermediate files.
test script shows the CMake configuration process, compilation progress, and test results in order. It generates code coverage report in the end. When something goes wrong, scripts stop immediately. The possible reason of a failed build could be:
- CMake configuration failed
- Build failed
- Test failed
- Code coverage failed
Testing All Modules¶
Test every modules:
Test all modules with clean build:
Testing Core Module¶
Test core module:
Test core module with clean build:
./test core -clean
Testing Metrics Module¶
Test metrics module:
Test metrics module with clean build:
./test metrics -clean
Testing Rules Module¶
Test rules module:
Test rules module with clean build:
./test rules -clean
Testing Reporters Module¶
Test reporters module:
Test reporters module with clean build:
./test reporters -clean
Reviewing Test Results¶
We could always go back and review our test results (unless we have cleaned test directory with
-clean option or delete that folder manually). There is an easy way to do it with
-show option to the
By default, it shows the test results for all modules. We can also explicitly specify the module name as an option to it. For example, show test result for all modules:
Show test results for core module:
./test core -show
Show test results for metrics module:
./test metrics -show
Show test results for rules module:
./test rules -show
Show test results for reporters module:
./test reporters -show