drskalman commented 4 years ago

[x] Verify Kagome build in the docker container.
[x] Verify Kagome build on the latest LTS Ubunutu.
[x] Otherwise communicate with Kagome team.
[x] Discuss the problem with Hunter and reproducibility with Kagome team.

FlorianFranzen commented 4 years ago

Building Kagome

Based on revision c1980abef6a3ceb4d0166a95112e3a1408c490ad

Kagome is build with CMake. By default most dependencies are downloaded and build by the CMake package manger "hunter" locally in the ~/.hunter subfolder. These dependecies might then download additional dependencies through hunter, etc. This all happens in the configure step of the build, when CMake is used to generate the final build files (e.g. Makefiles by default).

Therefore the project depends on cmake, make, a cmake compatible compiler (both come with build-essential on Debian and friends) and a recent version of rust and cargo (to build sr25519-crust).

For an out of source build you just have to run the following at the base of repo:

mkdir build && cd build
cmake .. && make

About Hunter

Hunter often also adds CMake package config files for the dependencies downloaded and build through it. As a result, as not all of them provide their own when installed by other means, CMake is currently not able to find many already installed dependencies when hunter is disabled.

However to make it easier to build and package Kagome, one should be able to build the codebase with all dependencies being provided externally and hunter being disabled with HUNTER_ENABLED=false.

A good resource on how hunter can be integrated with a project is the hunter gate repo.

Installation

To install kagome a make install after running cmake is enough.

However the node binary is currently not installed, so I currently use the following patch to build my docker test images.

--- a/examples/kagome_full/CMakeLists.txt
+++ b/examples/kagome_full/CMakeLists.txt
@@ -23,3 +23,5 @@ target_link_libraries(kagome_full
     local_key_storage
     primitives
     )
+
+kagome_install(kagome_full)

Dependencies

Some dependencies are Git submodules, some are installed through hunter.

Managed as submodules

Simple and still somewhat clean solution to manage dependencies and good for small header-only dependencies that still track upstream progress. These do not depend on hunter being enabled.

JSONRPC-lean (deps/jsonrpc-lean)

Source: https://github.com/uskr/jsonrpc-lean Revision: 534a9cd0280c3158f3d10abb9f5876bf01c9261e

Equals to latest commit from 2017-11-16, no versioning Header only

Dependencies: RapidJSON

sml

Source: https://github.com/boost-experimental/sml Revision: v1.1.0

Equals latest release from 2019-01-09, still maintained. Header only

Managed by hunter

Currently CMake ignores all package modules to resolve the dependencies provided by hunter. This makes it impossible to use custom find_package modules to locate dependencies that do not come with CMake package configs out of the box.

[ ] Drop CONFIG requirements to allow MODULE based detection where sensible

GTest and GMock

Good CMake support for GTest.

Could not get it to find GMock without hunter, but might be my side.

[ ] Check what others are doing.

Boost

Good CMake support and therefore detected without hunter.

Had some issues with imported targets, but might be on my side.

leveldb

No cmake support till 1.21 and path fix upstream but unreleased

[ ] Check if 1.21 is detected without hunter

xxhash

Is not detected without hunter, no pkg-config support before 0.73

[ ] Detect xxhash without hunter, e.g. through pkg-config

iroha ed25519

Source: https://github.com/hyperledger/iroha-ed25519

Uses hunter itself to fetch OpenSSL, but builds fine with hunter disabled.

Exports CMake package config and is detected without hunter.

sr25519-crust

Source: https://github.com/Warchant/sr25519-crust

A cbindgen wrapper around W3F's snorrkel crate. Depends on rustc and cargo to build.

Exports CMake package config and is detected without hunter.

[ ] CMake package config is hardcoded (e.g. break if installed to lib64)
[ ] Missing cargo.lock file!

I quickly patched the code for my own needs here. However the library will need a proper fix to generate package configs valid on all systems.

binaryen

Source: https://github.com/WebAssembly/binaryen

No cmake or pkg-config support

[ ] Detect libbinaryen without hunter

OpenSSL

Is detected by CMake without hunter.

Protobuf

Is detected by CMake without hunter

RapidJSON

Detection works for 1.1.0 without hunter.

Had some issues with imported targets, but might be on my side.

Microsoft.GSL

Version 2.1.0 produces deprecation error.

[ ] Check detection without hunter

spdlog

At least version 1.4.2 is required for detection without hunter Header only (supports partial compilation)

libp2p

Source: https://github.com/soramitsu/libp2p Revision: a93e6157b3b8d03b3534a4217e557d52b874d8ec

Use older version from 2019-11-29, missing ca. 25 new commits. Has many of the same dependencies and uses hunter as well.

Implements custom CMake protobuf generation function, which did not work in my build sandbox. Using the build-in function fixes this issue.

[ ] Update dependency?
[ ] Use CMake's buid-in protobuf support

TSL Hat Tries

Source: https://github.com/masterjedy/hat-trie

Uses latest version of a custom fork of library. Header only

[ ] Submit changes upstream

Boost-DI

Source: https://github.com/masterjedy/di

Use latest version of custom fork that adds CMake support Header only

[ ] Submit changes upstream

Other issues

The Kagome and cpp-libp2p CMake package config is not based on CMake recommendations and is not looking for its dependecies:

include(CMakeFindDependencyMacro)
find_dependency(<dependency>)

Currently C++17 is enabled through a toolchain file by setting CMAKE_TOOLCHAIN_FILE in the main CMakeLists.txt. This breaks a lot of CMake's default behavior, e.g. it then ignores any environmental variables like CMAKE_PREFIX_PATH, etc. I am not sure if that is how toolchain files are supposed to be used, as I have only encountered them when cross-compiling.