A single Kudu source tree may be used for multiple builds, each with itsown build directory. Build directories may be placed anywhere in thefilesystem with the exception of the root directory of the source tree. TheKudu build is invoked with a working directory of the build directoryitself, so you must ensure it exists (i.e. create it with mkdir -p). It’srecommended to place all build directories within the build subdirectory;build/latest will be symlinked to most recently created one.

The rest of this document assumes the build directory<root directory of kudu source tree>/build/debug.

The script thirdparty/build-if-necessary.sh is invoked by cmake, sonew thirdparty dependencies added by other developers will be downloadedand built automatically in subsequent builds if necessary.

To disable the automatic invocation of build-if-necessary.sh, set theNO_REBUILD_THIRDPARTY environment variable:

This can be particularly useful when trying to run tools like git bisectbetween two commits which may have different dependencies.

The build artifacts, including the test binaries, will be stored inbuild/debug/bin/.

To omit the Kudu unit tests during the build, add -DNO_TESTS=1 to theinvocation of cmake. For example:

AddressSanitizer is a nice clang feature which can detect many types of memoryerrors. The Jenkins setup for kudu runs these tests automatically on a regularbasis, but if you make large changes it can be a good idea to run it locallybefore pushing. To do so, you’ll need to build using clang:

The tests will run significantly slower than without ASAN enabled, and if anymemory error occurs, the test that triggered it will fail. You can then use acommand like:

to run just the failed test.

Similar to the above, you can use a special set of clang flags to enable the UndefinedBehavior Sanitizer. This will generate errors on certain pieces of code which maynot themselves crash but rely on behavior which isn’t defined by the C++ standard(and thus are likely bugs). To enable UBSAN, follow the same directions as forASAN above, but pass the -DKUDU_USE_UBSAN=1 flag to the cmake invocation.

In order to get a stack trace from UBSan, you can use gdb on the failing test, andset a breakpoint as follows:

Then, when the breakpoint fires, gather a backtrace as usual using the bt command.

ThreadSanitizer (TSAN) is a feature of recent Clang and GCC compilers which candetect improperly synchronized access to data along with many other threadingbugs. To enable TSAN, pass -DKUDU_USE_TSAN=1 to the cmake invocation,recompile, and run tests. For example:

TSAN may truncate a few lines of the stack trace when reporting where the erroris. This can be bewildering. It’s documented for TSANv1 here:https://code.google.com/p/data-race-test/wiki/ThreadSanitizerAlgorithmIt is not mentioned in the documentation for TSANv2, but has been observed.In order to find out what is really happening, set a breakpoint on the TSANreport in GDB using the following incantation:

In order to generate a code coverage report, you must use the following flags:

This will generate the code coverage files with extensions .gcno and .gcda. You can thenuse a tool like gcovr or llvm-cov gcov to visualize the results. For example, usinggcovr:

Then open cov_html/coverage.html in your web browser.

Kudu uses cpplint.py from Google to enforce coding style guidelines. You can run thelint checks via cmake using the ilint target:

This will scan any file which is dirty in your working tree, or changed since the lastgerrit-integrated upstream change in your git log. If you really want to do a fullscan of the source tree, you may use the lint target instead.

Kudu also uses the clang-tidy tool from LLVM to enforce coding styleguidelines. You can run the tidy checks via cmake using the tidy target:

This will scan any changes in the latest commit in the local tree. At the timeof writing, it will not scan any changes that are not locally committed.

Kudu uses the IWYUtool to keep the set of headers in the C++ source files consistent. For moreinformation on what consistent means, seeWhy IWYU.

You can run the IWYU checks via cmake using the iwyu target:

This will scan any file which is dirty in your working tree, or changed since the lastgerrit-integrated upstream change in your git log.

If you want to run against a specific file, or against all files, you can use theiwyu.py script:

See the output of iwyu.py --help for details on various modes of operation.

Kudu’s documentation is written in asciidoc and lives in the docs subdirectory.

To build the documentation (this is primarily useful if you would like toinspect your changes before submitting them to Gerrit), use the docs target:

This will invoke docs/support/scripts/make_docs.sh, which requiresasciidoctor to process the doc sources and produce the HTML documentation,emitted to build/docs. This script requires ruby and gem to be installedon the system path, and will attempt to install asciidoctor and other relateddependencies into $HOME/.gems using bundler.

To update the documentation that is integrated into the Kudu web site,including Java and C++ client API documentation, you may run the followingcommand:

This script will use your local Git repository to check out a shallow clone ofthe 'gh-pages' branch and use make_docs.sh to generate the HTML documentationfor the web site. It will also build the Javadoc and Doxygen documentation.These will be placed inside the checked-out web site, along with a tarballcontaining only the generated documentation (the docs/ and apidocs/ pathson the web site). Everything can be found in the build/site subdirectory.

You can proceed to commit the changes in the pages repository and send a codereview for your changes. In the future, this step may be automated wheneverchanges are checked into the main Kudu repository.

After making changes to the gh-pages branch, follow the instructions belowwhen you want to deploy those changes to the live web site.

When the documentation is updated on the gh-pages branch, or when other website files on that branch are updated, the following procedure can be used todeploy the changes to the official Apache Kudu web site. Committers havepermissions to publish changes to the live site.

The kudu build is compatible with ccache. Simply install your distro’s ccache package,prepend /usr/lib/ccache to your PATH, and watch your object files get cached. Linktimes won’t be affected, but you will see a noticeable improvement in compilationtimes. You may also want to increase the size of your cache using "ccache -M new_size".

One of the major time sinks in the Kudu build is linking. GNU ld is historicallyquite slow at linking large C++ applications. The alternative linker gold is muchbetter at it. It’s part of the binutils package in modern distros (try binutils-goldin older ones). To enable it, simply repoint the /usr/bin/ld symlink from ld.bfd told.gold.

Note that gold doesn’t handle weak symbol overrides properly (seethis bug report for details).As such, it cannot be used with shared objects (see below) because it’ll causetcmalloc’s alternative malloc implementation to be ignored.

Kudu can be built into shared objects, which, when used with ccache, can result in adramatic build time improvement in the steady state. Even after a make clean in the buildtree, all object files can be served from ccache. By default, debug and fastdebug willuse dynamic linking, while other build types will use static linking. To enabledynamic linking explicitly, run:

Subsequent builds will create shared objects instead of archives and use them whenlinking the kudu binaries and unit tests. The full range of options for KUDU_LINK arestatic, dynamic, and auto. The default is auto and only the first lettermatters for the purpose of matching.