These instructions assume you have a C++ development environment ready with Git, Python, Conan, CMake, and a C++ compiler. For help setting one up on Linux, macOS, or Windows, see this guide. |
These instructions also assume a basic familiarity with Conan and CMake. If you are unfamiliar with Conan, you can read our crash course or the official Getting Started walkthrough.
For a stable release, choose the master
branch or one of the tagged
releases.
git checkout master
For the latest release candidate, choose the release
branch.
git checkout release
For the latest set of untested features, or to contribute, choose the develop
branch.
git checkout develop
See System Requirements.
Building rippled generally requires git, Python, Conan, CMake, and a C++ compiler. Some guidance on setting up such a C++ development environment can be found here.
rippled
is written in the C++20 dialect and includes the <concepts>
header.
The minimum compiler versions required are:
Compiler | Version |
---|---|
GCC | 11 |
Clang | 13 |
Apple Clang | 13.1.6 |
MSVC | 19.23 |
The Ubuntu operating system has received the highest level of quality assurance, testing, and support.
Here are sample instructions for setting up a C++ development environment on Linux.
Many rippled engineers use macOS for development.
Here are sample instructions for setting up a C++ development environment on macOS.
Windows is not recommended for production use at this time.
- Additionally, 32-bit Windows development is not supported.
After you have a C++ development environment ready with Git, Python, Conan, CMake, and a C++ compiler, you may need to set up your Conan profile.
These instructions assume a basic familiarity with Conan and CMake.
If you are unfamiliar with Conan, then please read this crash course or the official Getting Started walkthrough.
You'll need at least one Conan profile:
conan profile new default --detect
Update the compiler settings:
conan profile update settings.compiler.cppstd=20 default
Linux developers will commonly have a default Conan profile that compiles
with GCC and links with libstdc++.
If you are linking with libstdc++ (see profile setting compiler.libcxx
),
then you will need to choose the libstdc++11
ABI:
conan profile update settings.compiler.libcxx=libstdc++11 default
Ensure inter-operability between boost::string_view
and std::string_view
types:
conan profile update 'conf.tools.build:cxxflags+=["-DBOOST_BEAST_USE_STD_STRING_VIEW"]' default
conan profile update 'env.CXXFLAGS="-DBOOST_BEAST_USE_STD_STRING_VIEW"' default
If you have other flags in the conf.tools.build
or env.CXXFLAGS
sections, make sure to retain the existing flags and append the new ones. You can check them with:
conan profile show default
Windows developers may need to use the x64 native build tools. An easy way to do that is to run the shortcut "x64 Native Tools Command Prompt" for the version of Visual Studio that you have installed.
Windows developers must also build rippled
and its dependencies for the x64
architecture:
conan profile update settings.arch=x86_64 default
When /usr/bin/g++
exists on a platform, it is the default cpp compiler. This
default works for some users.
However, if this compiler cannot build rippled or its dependencies, then you can
install another compiler and set Conan and CMake to use it.
Update the conf.tools.build:compiler_executables
setting in order to set the correct variables (CMAKE_<LANG>_COMPILER
) in the
generated CMake toolchain file.
For example, on Ubuntu 20, you may have gcc at /usr/bin/gcc
and g++ at /usr/bin/g++
; if that is the case, you can select those compilers with:
conan profile update 'conf.tools.build:compiler_executables={"c": "/usr/bin/gcc", "cpp": "/usr/bin/g++"}' default
Replace /usr/bin/gcc
and /usr/bin/g++
with paths to the desired compilers.
It should choose the compiler for dependencies as well,
but not all of them have a Conan recipe that respects this setting (yet).
For the rest, you can set these environment variables.
Replace <path>
with paths to the desired compilers:
conan profile update env.CC=<path> default
conan profile update env.CXX=<path> default
Export our Conan recipe for Snappy. It does not explicitly link the C++ standard library, which allows you to statically link it with GCC, if you want.
# Conan 1.x
conan export external/snappy snappy/1.1.10@
# Conan 2.x
conan export --version 1.1.10 external/snappy
Export our Conan recipe for RocksDB. It does not override paths to dependencies when building with Visual Studio.
# Conan 1.x
conan export external/rocksdb rocksdb/6.29.5@
# Conan 2.x
conan export --version 6.29.5 external/rocksdb
Export our Conan recipe for SOCI. It patches their CMake to correctly import its dependencies.
# Conan 1.x
conan export external/soci soci/4.0.3@
# Conan 2.x
conan export --version 4.0.3 external/soci
-
Create a build directory and move into it.
mkdir .build cd .build
You can use any directory name. Conan treats your working directory as an install folder and generates files with implementation details. You don't need to worry about these files, but make sure to change your working directory to your build directory before calling Conan.
Note: You can specify a directory for the installation files by adding the
install-folder
or-if
option to everyconan install
command in the next step. -
Generate CMake files for every configuration you want to build.
conan install .. --output-folder . --build missing --settings build_type=Release conan install .. --output-folder . --build missing --settings build_type=Debug
For a single-configuration generator, e.g.
Unix Makefiles
orNinja
, you only need to run this command once. For a multi-configuration generator, e.g.Visual Studio
, you may want to run it more than once.Each of these commands should also have a different
build_type
setting. A second command with the samebuild_type
setting will overwrite the files generated by the first. You can pass the build type on the command line with--settings build_type=$BUILD_TYPE
or in the profile itself, under the section[settings]
with the keybuild_type
.If you are using a Microsoft Visual C++ compiler, then you will need to ensure consistency between the
build_type
setting and thecompiler.runtime
setting.When
build_type
isRelease
,compiler.runtime
should beMT
.When
build_type
isDebug
,compiler.runtime
should beMTd
.conan install .. --output-folder . --build missing --settings build_type=Release --settings compiler.runtime=MT conan install .. --output-folder . --build missing --settings build_type=Debug --settings compiler.runtime=MTd
-
Configure CMake and pass the toolchain file generated by Conan, located at
$OUTPUT_FOLDER/build/generators/conan_toolchain.cmake
.Single-config generators:
cmake -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release ..
Pass the CMake variable
CMAKE_BUILD_TYPE
and make sure it matches thebuild_type
setting you chose in the previous step.Multi-config generators:
cmake -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake ..
Note: You can pass build options for
rippled
in this step. -
Build
rippled
.For a single-configuration generator, it will build whatever configuration you passed for
CMAKE_BUILD_TYPE
. For a multi-configuration generator, you must pass the option--config
to select the build configuration.Single-config generators:
cmake --build .
Multi-config generators:
cmake --build . --config Release cmake --build . --config Debug
-
Test rippled.
Single-config generators:
./rippled --unittest
Multi-config generators:
./Release/rippled --unittest ./Debug/rippled --unittest
The location of
rippled
in your build directory depends on your CMake generator. Pass--help
to see the rest of the command line options.
The coverage report is intended for developers using compilers GCC
or Clang (including Apple Clang). It is generated by the build target coverage
,
which is only enabled when the coverage
option is set, e.g. with
--options coverage=True
in conan
or -Dcoverage=ON
variable in cmake
Prerequisites for the coverage report:
- gcovr tool (can be installed e.g. with pip)
gcov
for GCC (installed with the compiler by default) orllvm-cov
for Clang (installed with the compiler by default)Debug
build type
A coverage report is created when the following steps are completed, in order:
rippled
binary built with instrumentation data, enabled by thecoverage
option mentioned above- completed run of unit tests, which populates coverage capture data
- completed run of the
gcovr
tool (which internally invokes eithergcov
orllvm-cov
) to assemble both instrumentation data and the coverage capture data into a coverage report
The above steps are automated into a single target coverage
. The instrumented
rippled
binary can also be used for regular development or testing work, at
the cost of extra disk space utilization and a small performance hit
(to store coverage capture). In case of a spurious failure of unit tests, it is
possible to re-run the coverage
target without rebuilding the rippled
binary
(since it is simply a dependency of the coverage report target). It is also possible
to select only specific tests for the purpose of the coverage report, by setting
the coverage_test
variable in cmake
The default coverage report format is html-details
, but the user
can override it to any of the formats listed in Builds/CMake/CodeCoverage.cmake
by setting the coverage_format
variable in cmake
. It is also possible
to generate more than one format at a time by setting the coverage_extra_args
variable in cmake
. The specific command line used to run the gcovr
tool will be
displayed if the CODE_COVERAGE_VERBOSE
variable is set.
By default, the code coverage tool runs parallel unit tests with --unittest-jobs
set to the number of available CPU cores. This may cause spurious test
errors on Apple. Developers can override the number of unit test jobs with
the coverage_test_parallelism
variable in cmake
.
Example use with some cmake variables set:
cd .build
conan install .. --output-folder . --build missing --settings build_type=Debug
cmake -DCMAKE_BUILD_TYPE=Debug -Dcoverage=ON -Dcoverage_test_parallelism=2 -Dcoverage_format=html-details -Dcoverage_extra_args="--json coverage.json" -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake ..
cmake --build . --target coverage
After the coverage
target is completed, the generated coverage report will be
stored inside the build directory, as either of:
- file named
coverage.
extension , with a suitable extension for the report format, or - directory named
coverage
, with theindex.html
and other files inside, for thehtml-details
orhtml-nested
report formats.
Option | Default Value | Description |
---|---|---|
assert |
OFF | Enable assertions. |
reporting |
OFF | Build the reporting mode feature. |
coverage |
OFF | Prepare the coverage report. |
tests |
ON | Build tests. |
unity |
ON | Configure a unity build. |
san |
N/A | Enable a sanitizer with Clang. Choices are thread and address . |
Unity builds may be faster for the first build
(at the cost of much more memory) since they concatenate sources into fewer
translation units. Non-unity builds may be faster for incremental builds,
and can be helpful for detecting #include
omissions.
After any updates or changes to dependencies, you may need to do the following:
- Remove your build directory.
- Remove the Conan cache:
rm -rf ~/.conan/data
- Re-run conan install.
If your compiler version is recent enough to have removed std::result_of
as
part of C++20, e.g. Apple Clang 15.0, then you might need to add a preprocessor
definition to your build.
conan profile update 'options.boost:extra_b2_flags="define=BOOST_ASIO_HAS_STD_INVOKE_RESULT"' default
conan profile update 'env.CFLAGS="-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"' default
conan profile update 'env.CXXFLAGS="-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"' default
conan profile update 'conf.tools.build:cflags+=["-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"]' default
conan profile update 'conf.tools.build:cxxflags+=["-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"]' default
If you are compiling with an early version of Clang 16, then you might hit a regression when compiling C++20 that manifests as an error in a Boost header. You can workaround it by adding this preprocessor definition:
conan profile update 'env.CXXFLAGS="-DBOOST_ASIO_DISABLE_CONCEPTS"' default
conan profile update 'conf.tools.build:cxxflags+=["-DBOOST_ASIO_DISABLE_CONCEPTS"]' default
If you get a linker error suggesting that you recompile Boost with position-independent code, such as:
/usr/bin/ld.gold: error: /home/username/.conan/data/boost/1.77.0/_/_/package/.../lib/libboost_container.a(alloc_lib.o):
requires unsupported dynamic reloc 11; recompile with -fPIC
Conan most likely downloaded a bad binary distribution of the dependency.
This seems to be a bug in Conan just for Boost 1.77.0 compiled with GCC
for Linux. The solution is to build the dependency locally by passing
--build boost
when calling conan install
.
conan install --build boost ...
If you want to experiment with a new package, follow these steps:
- Search for the package on Conan Center.
- Modify
conanfile.py
:- Add a version of the package to the
requires
property. - Change any default options for the package by adding them to the
default_options
property (with syntax'$package:$option': $value
).
- Add a version of the package to the
- Modify
CMakeLists.txt
:- Add a call to
find_package($package REQUIRED)
. - Link a library from the package to the target
ripple_libs
(search for the existing call totarget_link_libraries(ripple_libs INTERFACE ...)
).
- Add a call to
- Start coding! Don't forget to include whatever headers you need from the package.
Footnotes
-
It is possible to build with Conan 2.x, but the instructions are significantly different, which is why we are not recommending it yet. Notably, the
conan profile update
command is removed in 2.x. Profiles must be edited by hand. ↩