Compiling a debug version of ArangoDB is a must for everyone that wants to modify the C++ ArangoDB source code and test their changes locally.
How to do this is different in the 2.8 and 3.0 branches of ArangoDB, but luckily it’s really easy to achieve in both branches.
ArangoDB 2.8
For the 2.8 branch of ArangoDB, clone the 2.8 version of the ArangoDB repository first:
1 2 |
|
And in that directory execute the following commands:
1 2 3 4 5 |
|
(note that you’ll need a working C++11 compiler and some prerequisites such as the OpenSSL library, GNU Bison and Flex installed for this to work).
This will compile ArangoDB and all of its dependencies, and finally
make them available in the bin
subdirectory of the current directory.
There is no need to install ArangoDB using make install
. arangod and
the client tools can be run locally using the following commands:
1 2 |
|
Now, after any modification to the ArangoDB C++ source code you can re-compile
using make
. This will only rebuild the things that need to be rebuilt. If the
build is successful, the changes you have made should be visible when restarting
the binaries.
As the -g
option used above will have configured a build with debug
symbols, it’s also possible to use a debugger such as gdb for stepping
through the executables, attach to the while they are running, or to
obtain stack traces in case any of the executables crashed.
ArangoDB 3.0
For the 3.0 branch of ArangoDB, it’s required to once clone that version of the ArangoDB repository into a local directory:
1 2 |
|
In that directory execute the following commands to configure the build for debugging:
1
|
|
(again you’ll need a working C++11 compiler and some prerequisites such as the OpenSSL library installed for this to work).
This will configure the build to be a debug build, with debug symbols but most optimizations disabled. To build ArangoDB, just execute:
1
|
|
To execute one of the binaries, run them from the checkout directory as follows:
1 2 |
|
After any modification to the ArangoDB C++ source code, build again
using (cd build && make -j4)
to see the changes in effect.
The build is a debug build, meaning you can use a debugger and get
meaningful stack traces for core dumps produced by the binaries.
If you got, then I strongly recommend to also enable the
Address Sanitizer
(ASAN) for your debug build. This can greatly help finding common memory usage
errors during development. There is another
blog post about using ASAN in ArangoDB development.