Mirror of Apache Kudu
// Licensed to the Apache Software Foundation (ASF) under one // or more contributor license agreements. See the NOTICE file // distributed with this work for additional information // regarding copyright ownership. The ASF licenses this file // to you under the Apache License, Version 2.0 (the // "License"); you may not use this file except in compliance // with the License. You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, // software distributed under the License is distributed on an // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY // KIND, either express or implied. See the License for the // specific language governing permissions and limitations // under the License. = Kudu Developer Documentation
== Building and installing Kudu
Follow the steps in the https://kudu.apache.org/docs/installation.html#build_from_source[documentation] to build and install Kudu from source
=== Building Kudu out of tree
A single Kudu source tree may be used for multiple builds, each with its own build directory. Build directories may be placed anywhere in the filesystem with the exception of the root directory of the source tree. The Kudu build is invoked with a working directory of the build directory itself, so you must ensure it exists (i.e. create it with mkdir -p). It's recommended 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 /build/debug.
=== Automatic rebuilding of dependencies
The script thirdparty/build-if-necessary.sh is invoked by cmake, so
new thirdparty dependencies added by other developers will be downloaded
and built automatically in subsequent builds if necessary.
To disable the automatic invocation of build-if-necessary.sh, set the
NO_REBUILD_THIRDPARTY environment variable:
This can be particularly useful when trying to run tools like git bisect
between two commits which may have different dependencies.
=== Building Kudu itself
The build artifacts, including the test binaries, will be stored in build/debug/bin/.
To omit the Kudu unit tests during the build, add -DNO_TESTS=1 to the invocation of cmake. For example:
== Running unit/functional tests
To run the Kudu unit tests, you can use the ctest command from within the
build/debug directory:
This command will report any tests that failed, and the test logs will be written to build/debug/test-logs.
Individual tests can be run by directly invoking the test binaries in build/debug/bin. Since Kudu uses the Google C++ Test Framework (gtest), specific test cases can be run with gtest flags:
gtest also allows more complex filtering patterns. See the upstream documentation for more details.
=== Running tests with the clang AddressSanitizer enabled
AddressSanitizer is a nice clang feature which can detect many types of memory
errors. The Jenkins setup for kudu runs these tests automatically on a regular
basis, but if you make large changes it can be a good idea to run it locally
before pushing. To do so, you'll need to build using clang:
The tests will run significantly slower than without ASAN enabled, and if any memory error occurs, the test that triggered it will fail. You can then use a command like:
to run just the failed test.
NOTE: For more information on AddressSanitizer, please see the https://clang.llvm.org/docs/AddressSanitizer.html[ASAN web page].
=== Running tests with the clang Undefined Behavior Sanitizer (UBSAN) enabled
Similar to the above, you can use a special set of clang flags to enable the Undefined
Behavior Sanitizer. This will generate errors on certain pieces of code which may
not 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 for
ASAN 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, and set a breakpoint as follows:
Then, when the breakpoint fires, gather a backtrace as usual using the bt command.
=== Running tests with ThreadSanitizer enabled
ThreadSanitizer (TSAN) is a feature of recent Clang and GCC compilers which can
detect improperly synchronized access to data along with many other threading
bugs. To enable TSAN, pass -DKUDU_USE_TSAN=1 to the cmake invocation,
recompile, and run tests. For example:
$ mkdir -p build/tsan
$ cd build/tsan
$ CC=../../thirdparty/clang-toolchain/bin/clang
CXX=../../thirdparty/clang-toolchain/bin/clang++
../../thirdparty/installed/common/bin/cmake
-DKUDU_USE_TSAN=1 ../..
$ make -j8
TSAN may truncate a few lines of the stack trace when reporting where the error is. This can be bewildering. It's documented for TSANv1 here: https://code.google.com/p/data-race-test/wiki/ThreadSanitizerAlgorithm It 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 TSAN report in GDB using the following incantation:
=== Generating code coverage reports
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 then
use a tool like gcovr or llvm-cov gcov to visualize the results. For example, using
gcovr:
$ cd build/coverage
$ mkdir cov_html
$ ../../thirdparty/installed/common/bin/gcovr
--gcov-executable=$(pwd)/../../build-support/llvm-gcov-wrapper
--html --html-details -o cov_html/coverage.html
Then open cov_html/coverage.html in your web browser.
=== Running lint checks
Kudu uses cpplint.py from Google to enforce coding style guidelines. You can run the
lint checks via cmake using the ilint target:
This will scan any file which is dirty in your working tree, or changed since the last
gerrit-integrated upstream change in your git log. If you really want to do a full
scan of the source tree, you may use the lint target instead.
=== Running clang-tidy checks
Kudu also uses the clang-tidy tool from LLVM to enforce coding style
guidelines. 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 time of writing, it will not scan any changes that are not locally committed.
=== Running include-what-you-use (IWYU) checks
Kudu uses the https://github.com/include-what-you-use/include-what-you-use[IWYU] tool to keep the set of headers in the C++ source files consistent. For more information on what consistent means, see https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/WhyIWYU.md[_Why 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 last gerrit-integrated upstream change in your git log.
If you want to run against a specific file, or against all files, you can use the
iwyu.py script:
See the output of iwyu.py --help for details on various modes of operation.
[[building-docs]] === Building Kudu documentation
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 to
inspect your changes before submitting them to Gerrit), use the docs target:
This will invoke docs/support/scripts/make_docs.sh, which requires
asciidoctor to process the doc sources and produce the HTML documentation,
emitted to build/docs. This script requires ruby and gem to be installed
on the system path, and will attempt to install asciidoctor and other related
dependencies into $HOME/.gems using https://bundler.io/[bundler].
Some of the dependencies require a recent version of Ruby. To build the documentation on a system that comes with an older Ruby version (such as Ruby 2.0 on CentOS 7), it is easiest to use https://github.com/rbenv/rbenv[rbenv] to install Ruby 2.7.
WARNING: As the default values for some configuration options differ between Mac
and Linux (e.g. file vs log block manager) and the configuration reference is
generated by running the binaries with -help, the documentation MUST NOT be
generated on Mac for publishing purposes, only for verification.
NOTE: Java API docs can only be built on Java 8 due to Javadoc compatibility issues.
[[updating-the-site]] === Updating the Kudu web site documentation
To update the documentation that is integrated into the Kudu web site, including Java and C++ client API documentation, you may run the following command:
This script will use your local Git repository to check out a shallow clone of
the 'gh-pages' branch and use make_docs.sh to generate the HTML documentation
for 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 tarball
containing only the generated documentation (the docs/ and apidocs/ paths
on the web site). Everything can be found in the build/site subdirectory.
To build the C++ Client API you need to have Doxygen 1.8.19 or later which is fairly new so you might need to https://www.doxygen.nl/manual/install.html#install_src_unix[build it from source]. To build it on RHEL/CentOS you'll also need https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/[devtoolset] as Doxygen uses {cpp}14 since 1.8.17.
You can proceed to commit the changes in the pages repository and send a code review for your changes. In the future, this step may be automated whenever changes are checked into the main Kudu repository.
After making changes to the gh-pages branch, follow the instructions below
when you want to deploy those changes to the live web site.
WARNING: The site MUST NOT be built on Mac for publishing purposes, only for verification. See the warning in <> for details.
=== Deploying changes to the Apache Kudu web
No open issues yet, or sync has not completed.