Build Types

DuckDB can be built in many different settings, most of these correspond directly to CMake but not all of them.

release

This build has been stripped of all the assertions and debug symbols and code, optimized for performance.

debug

This build runs with all the debug information, including symbols, assertions and #ifdef DEBUG blocks. Due to these, binaries of this build are expected to be slow. Note: the special debug defines are not automatically set for this build.

relassert

This build does not trigger the #ifdef DEBUG code blocks but it still has debug symbols that make it possible to step through the execution with line number information and D_ASSERT lines are still checked in this build. Binaries of this build mode are significantly faster than those of the debug mode.

reldebug

This build is similar to relassert in many ways, only assertions are also stripped in this build.

benchmark

This build is a shorthand for release with BUILD_BENCHMARK=1 set.

tidy-check

This creates a build and then runs Clang-Tidy to check for issues or style violations through static analysis. The CI will also run this check, causing it to fail if this check fails.

format-fix | format-changes | format-main

This doesn't actually create a build, but uses the following format checkers to check for style issues:

• clang-format to fix format issues in the code.
• cmake-format to fix format issues in the CMakeLists.txt files.

The CI will also run this check, causing it to fail if this check fails.

Extension Selection

Core DuckDB extensions are the ones maintained by the DuckDB team. These are hosted in the duckdb GitHub organization and are served by the core extension repository.

Additional extensions can be built as part of DuckDB via the BUILD_EXTENSIONS flag, then listing the names of the extensions that are to be built.

BUILD_EXTENSIONS='tpch;httpfs;fts;json;parquet' make

More on this topic at building DuckDB extensions.

Package Flags

The Makefile has flags to control which components are built. These can be enabled by either setting them in the current env, through set up files like bashrc or zshrc, or by setting them before the call to make, for example:

BUILD_BENCHMARK=1 make debug

The Python, Java (JDBC) and ODBC clients are maintained in separate repositories and are no longer built from the main DuckDB repository. See the Python, Java and ODBC repositories for their build instructions.

BUILD_BENCHMARK

When this flag is set, DuckDB's in-house benchmark suite is built. More information about this can be found in the README.

DISABLE_SHELL

The CLI is built by default. When this flag is set, the CLI is not built.

Miscellaneous Flags

DISABLE_UNITY

To improve compilation time, we use Unity Build to combine translation units. This can however hide include bugs, this flag disables using the unity build so these errors can be detected.

DISABLE_SANITIZER

In some situations, running an executable that has been built with sanitizers enabled is not supported / can cause problems. Julia is an example of this. With this flag enabled, the sanitizers are disabled for the build.

Overriding Git Hash and Version

It is possible to override the Git hash and version when building from source using the OVERRIDE_GIT_DESCRIBE environment variable. This is useful when building from sources that are not part of a complete Git repository (e.g., an archive file with no information on commit hashes and tags). For example:

OVERRIDE_GIT_DESCRIBE=v0.10.0-843-g09ea97d0a9 GEN=ninja make

Will result in the following output when running ./build/release/duckdb:

v0.10.1-dev843 09ea97d0a9
...

Building without Git

Git and Python are optional dependencies for building DuckDB from source. DuckDB normally derives its version and commit hash from Git, so OVERRIDE_GIT_DESCRIBE is primarily useful when building from sources that are not a complete Git checkout. The version and commit hash are resolved as follows:

• If OVERRIDE_GIT_DESCRIBE is set to a full git describe --tags --long string (for example, v1.0.0-843-g09ea97d0a9), the version, the development iteration, and the commit hash are all extracted from it.
• If OVERRIDE_GIT_DESCRIBE is set to a version only (for example, v1.0.0), the remaining details are filled in from the current Git commit when Git is available.
• If OVERRIDE_GIT_DESCRIBE is not set and Git is available, DuckDB runs git describe --tags --long to determine the version and commit hash.
• If OVERRIDE_GIT_DESCRIBE is not set and Git is not available, DuckDB falls back to a placeholder version and commit hash, and logs a message during the CMake configuration step. The build still succeeds.