Developers guide

Build project

$ git clone https://github.com/hyperledger/iroha-ametsuchi
$ cd iroha-ametsuchi
$ mkdir build && cd build && cmake .. && make

You can change build configs via flags:
 -DCMAKE_BUILD_TYPE=Debug     (Debug/Release, default Debug)
 -DTESTING=On                 (build tests: On/Off, default On)
 -DBENCHMARKING=OFF           (build benchmarks: On/Off, default Off)
 -DDOCS=OFF                   (build doxygen docs: On/Off, default Off)

$ tree -L 1 .
├── benchmark                  # benchmark executables 
├── CMakeCache.txt
├── CMakeFiles
├── cmake_install.cmake
├── CTestTestfile.cmake
├── docs                       # doxygen docs
├── Doxyfile 
├── lib                        # libametsuchi
├── Makefile 
├── test
└── test_bin                   # test executables

Codestyle

We prefer google codestyle. We strictly recommend to use it. To save your time, we prepared .clang-format for tool clang-format and CPPLINT.cfg for tool cpplint, which can be easily integrated into your favourite IDE. For consistent line endings, source file encodings and similar issues, we use editorconfig.

These tools help us to not make stupid mistakes and keep our code clean and readable.

Namespaced includes

The main point of this section is to explain the reason of our decision to make namespaced includes.

Consider this code:

#include <ametsuchi/module_a/util.h>  // clean, namespaced
// and
#include <util.h> // how many util.h are there? a lot! 
// or, include from other module
#include "../../module_a/util.h" // ugly, isn't it?

Why can I write #include <ametsuchi/module_a/util.h> and it works?

Because our cmake file contains target_include_directories(ametsuchi ${PROJECT_SOURCE_DIR}/include)

Creating new components

If you want to create module with name HelloWorld (for example), then do the following:

1. if it is a single-header library:

include/ametsuchi/hello_world.h     // single-header library 
test/ametsuchi/hello_world.cc       // test for this library
benchmark/ametsuchi/hello_world.cc  // write benchmark, if applicable

2. if it is complex module with multiple files, then:

include/ametsuchi/hello_world/<headers>.h     // all headers files for module 
test/ametsuchi/hello_world/<sources>.cc       // test(s) for this module. Can be one or multiple, for each sub-component.
benchmark/ametsuchi/hello_world/<sources>.cc  // write benchmark, if applicable

Don't forget to add benchmark and test to according CMakeLists.txt:

# benchmark/CMakeLists.txt
AddBenchmark(hello_world_benchmark benchmark/ametsuchi/hello_world.cc)
# test/CMakeLists.txt
AddTest(hello_world_test test/ametsuchi/hello_world.cc)

Versioning policy

Releases are numbered according to semantic versioning.

Branch policy

We use GitHub flow with squash-and-merge pull requests.