ledger-core
|
Core library which will be used by Ledger applications.
If you’re a developer and want to contribute, please refer to our ./CONTRIBUTING.md "contribution guidelines" specific documentation.
If you had already forked / cloned the repository before issuing that command, it’s okay. You can initiate the submodules with the following commands:
This project is based on **_cmake_** as a build system so you should install it before starting (at least version 3.7).
**_cmake_** is building out of source, you should create a build directory (e.g. lib-ledger-core-build
):
. # Directory where clone command was launched ├── lib-ledger-core # Source files directory ├── lib-ledger-core-build # Build directory
If you respect this folder structure (and naming), after cd lib-ledger-core-build
, you can build the library by running:
(macOSX users) If you struggle to find where Qt5 is located, for example, on
macOSX
,qt5
can be found at:
Several CMake arguments might interest you there:
-DCMAKE_BUILD_TYPE=Debug
: you should always set that when testing as you will get DWARF debug symbols and debugging instruments support.-DCMAKE_EXPORT_COMPILE_COMMANDS=YES
: useful when you’re using a C++ linter, such as cquery.Building with JNI (Java Native Interface), allows you to use the library with Java based software. In order to enable JNI mode use
This will add JNI files to the library compilation and remove tests. You need at least a JDK 7 to build for JNI (OpenJDK or Oracle JDK)
You can build the core library or debug it from a docker image:
docker build -t ledger-core-env .
(considering that you are currently at the root of the repository)docker run -ti --cap-add=SYS_PTRACE --security-opt seccomp=unconfined ledger-core-env
docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -d ledger-core-env
docker ps
docker exec -ti :container_id zsh
where :container_id has to be replaced by the container you got from docker ps
Note: If you feel on fire you could use docker volumes to persist data.
It is possible to build the library with embedded version of OpenSSL (which is advised for Android and iOS builds) or you can rely on OpenSSL provided by the system.
To build the library with system's OpenSSL you should configure the project by providing -DSYS_OPENSSL=ON
option plus some additional variables to allow cmake
to find OpenSSL library:
-DOPENSSL_ROOT_DIR=<path-to-openssl-root-dir>
is needed, for example, if you installed OpenSSL through brew
you can pass: -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl
,-Linux: -OPENSSL_SSL_LIBRARIES=<path-to-openssl-libraries> -DOPENSSL_INCLUDE_DIR=<path-to-openssl-include-files>
, for example, if you installed OpenSSL through apt-get
it will look like: -DOPENSSL_SSL_LIBRARIES=/usr/lib/x86_64-linux-gnu -DOPENSSL_INCLUDE_DIR=/usr/include/openssl
In both cases we are supporting OpenSSL 1.0
and 1.1
.
You can generate the Doxygen documentation by running the doc
target (for instance, make doc
with makefiles).
The library can be compiled and integrated as an node module in a pretty straightforward way. You will be interested in either using it, or making a new version of the node module.
The lib-ledger-core-node-bindings repository contains the node.js bindings you will need to interface with lib-ledger-core
. You can either clone the git repository or simply install from npm
directly:
Generating bindings is a several steps process:
lib-ledger-core
and generate a fresh version of lib-ledger-core
.package.json
file in order to remove or comment the "preinstall"
line in "scripts"
.lib-ledger-core
, run the tools/generateBindings.sh
script by giving it the path to the bindings (i.e. where you cloned lib-ledger-core-node-bindings) and as second argument the path to the directory where you built the lib-ledger-core
— it should be something like $(your-lib-ledger-core-dir)/../lib-ledger-core-build
or $(your-lib-ledger-core-dir)/build
.lib-ledger-core/djinni
and run get fetch origin --prune && git rebase origin/master
.sbt
and java8
for a complete, working install.lib-ledger-core
— if any — with a git checkout .
and/or git reset .
.cd
into lib-ledger-core-bindings
and run yarn
to generate the bindings.build/Release/ledgerapp_nodejs.node
in the bindings project.npm i
should install your own version.Libcore can be built for following OSes:
macOS 9.0
, with x86_64
architecture,x86_64
architecture,MSVC
(starting from Visual Studio 15), 32-bit is built with MinGW
,x86_64
, armv7
and arm64
architectures are supported, minimum supported version is iOS 10.0
,x86
, armeabi-v7a
and arm64-v8a
architectures are supported, minimum supported version is Android 7 (API 24)
(Java 8 is needed). node
with version >=8.4.0
and <9.0.0
(other versions are not tested (yet)),python
with version 2.7.x
.You are advised to link your GitHub account to both CircleCI and Appveyor by signing-in. Because we are using shared runners and resources, we have to share CI power with other teams. It’s important to note that we don’t always need to run the CI. Example of situations when we do not need it:
In those cases, please include the [skip ci]
or [ci skip]
text in your commit message’s title. You could tempted to put it in the body of your message but that will not work with Appveyor.
Finally, it’s advised to put it on every commit and rebase at the end to remove the [skip ci]
tag from your commits’ messags to have the CI re-enabled, but some runners might be smart enough to do it for all commits in the PR.
Rebasing is done easily. If your PR wants to merge feature/stuff -> develop
, you can do something like this — assuming you have cloned the repository with a correctly set origin
remote:
Change the pick
to r
or reword
at the beginning of each lines without changing the text of the commits — this has no effect. Save the file and quit. You will be prompted to change the commits’ messages one by one, allowing you to remove the [skip ci]
tag from all commits.
Currently, interface files (headers, .hpp) are not linked by copied directly into the test directory. That means that every time you make a change in the interface that is tested by any code in core/test/, you need to update the copy.
Just run this command:
Especially if you’ve upgraded to Mojave for which there are some breaking changes, you will need to perform some manual tasks — here, for macOSX Mojave: