To compile the source code, you should create a folder to contain the compiled binaries and executables, run cmake to create the make file, then compile the code. The following demonstrates the steps needed on a Ubuntu machine. Other platforms are similar.
The Hello World C Example. #include int main(int argc, char.argv) std::cout. The make utility requires a file, Makefile (or makefile), which defines set of tasks to be executed. You may have used make to compile a program from source code. Most open source projects use make to compile a final executable binary, which can then be installed using make install.
For some platforms, such as Oracle Enterprise Linux 6, you may also need to install the devtoolset software collection.
If you get an error stating that the MySQL libraries cannot be found, then check the listed paths. If the client libraries or the
include folder does not exist, you may need to reference a compiled copy of the MySQL Server source code by using the
-DWITH_MYSQL=<path to server code> option. More specifically, the compiler needs to be able to find the MySQL client libraries and include files. If libmysqlclient is stored elsewhere, then
-DMySQL_CLIENT_LIB=/path/to/libmysqlclient.so can also be used. A compiled server source code tree will have these files. So too will most installations of the MySQL server.
For example, on Debian and RPM-based platforms, you would need the packages which contain the libraries and the development (include) files. If you installed MySQL from a platform-specific repository, you would need to install the
If you change anything and need to recompile from scratch, be sure to delete the
CMakeCache.txt file before running the
Begin by running the
cmake command to create the makefile. The following commands are run from the root of the MySQL Router source code tree. You should see similar results with the appropriate paths for your system.
Next, compile the code. For this we only need the
make command as shown. Again, you should see similar results on your system.
Continuous integration requires a robust test environment to be able to detect regressions as early as possible.
A typical test environment will typically be composed of integration tests of the whole system and unit tests per components.
This post explains how to create unit tests for a
C++ component using GoogleTest and CMake.
I will assume here that the project structure follows the model described in a previous post:
main subdirectory contains the main project target, an executable providing the super-useful
libfoo service using the awesome
libbar backend (for example
libfoo could be a generic face recognition library and
libbar a GPU-based image processing library).
test directory contains a single executable allowing to test the
libfoo service using a mock version of
From Wikipedia: In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways.
For those interested, the code for this sample project is on github.
##A closer look at the test directory
In my simplistic example, there is only one subdirectory under
test, but in a typical project, it would contain several subdirectories, one for each test program.
Tests programs are based on Google’s Googletest framework and its GoogleMock extension.
Since all test programs will be using these packages, the root
CMakeLists.txt file should contain all directives required to resolve the corresponding dependencies. This is where things get a bit hairy, since Google does not recommend to install these packages in binary form, but instead to recompile them with your project.
###Resolving GoogleTest and GoogleMock dependencies
There are at least three options to integrate your project with GoogleTest and GoogleMock.
####Having both packages integrated in your build system
Obviously, this is only an option if you actually do have a buildsystem, but if this is the case, this would be my recommendation.
Depending on how your buildsystem is structured, your mileage may vary, but in the end you should be able to declare GoogleTest and GoogleMock as dependencies using
CMake functions like the built-in
find_package or the
Makefiles For Dummies
####Add both packages sources to your project
Adding the GoogleTest and GoogleMock sources as subdirectories of
test would allow you to compile them as part of your project.
This is however really ugly, and I wouldn’t recommend you doing that …
####Add both packages as external CMake projects
According to various answers posted on StackOverflow, this seems to be the recommended way of resolving GoogleTest and GoogleMock dependencies on a per project basis.
It takes advantage of the
ExternalProject module to fetch GoogleTest and GoogleMock sources from the internet and compile them as third-party dependencies in your project.
Below is a working example, with a few comments explaining what’s going on:
Note: It should theoretically be possible to set the GoogleTest and GoogleMock include directories as target properties using the INTERFACE_INCLUDE_DIRECTORIES variable, but it fails because these directoires don’t exist yet when they are declared. As a workaround, I had to explicitly use include_directories to specify them.
###Writing a testfoo test program for libfoo
The testfoo program depends on libfoo, GoogleTest and GoogleMock.
Here is how the testfoo
CMakeLists.txt file would look like:
The libraries required for the build are listed under
target_link_libraries.CMake will then add the appropriate include directories and link options.
The testfoo program will provide unit tests for the
Foo class of the libfoo library defined below.
The sample Test program described in the GoogleTest Documentation fits in a single file, but I prefer splitting the Unit Tests code in three types of files.
main.cpp file will contain only the test program
main function.This is where you will put the generic Googletest Macro invocation to launch the tests and some initializations that need to be put in the
main (nothing in this particular case).
This file contains the declaration of the
FooTest class, which is the test fixture for the
Assuming the libbar library implements a public
Bar interface, we use GoogleMock to provide a fake implementation for test purposes only:
This will allow us to inject controlled values into the libfoo library when it will invoke the
Bar class methods.
Please refer to the GoogleMock documentation for a detailed description of the
This file contains the implementation of the
TestFoo fixture class.
Suttons garden planner 2020. This is where the actual tests are written.
We will test the output of the
Foo::baz() method, first having default values for the
Bar::norf() methods returned by our mock, then overrding the value returned by
Bar::norf() with a value specific to our test.
In all test cases, we use GoogleTest expectations to verify the output of the
Please refer to the GoogleTest documentation for a much detailed presentation of how to create unit tests with Gtest.
As usual, it is recommended to build your program out-of-tree, ie in a directory separated from the sources.
Makefiles In C++
First, you need to invoke the
cmake command to generate the build files.
This should produce an output similar to this one:
Then, build the project targets.
The following output corresponds to the case where GoogleTest and GoogleMock are automatically fetched from their repositories and built as third-party dependencies.
Once the test programs have been built, you can run them individually …
… producing a detailed output …
Note: You can get rid of GoogleMock warnings by using a nicemock.
Cmakelists Add Library
… or globally through
… producing only a test summary.