2020-04-09 10:51:16 -07:00
< p align = "center" >
< a href = "https://solana.com" >
2024-02-11 23:18:11 -08:00
< img alt = "Solana" src = "https://i.imgur.com/0vfIMHo.png" width = "250" / >
2020-04-09 10:51:16 -07:00
< / a >
< / p >
2018-06-24 10:10:55 -07:00
2020-04-09 10:55:00 -07:00
[![Solana crate ](https://img.shields.io/crates/v/solana-core.svg )](https://crates.io/crates/solana-core)
[![Solana documentation ](https://docs.rs/solana-core/badge.svg )](https://docs.rs/solana-core)
[![Build status ](https://badge.buildkite.com/8cc350de251d61483db98bdfc895b9ea0ac8ffa4a32ee850ed.svg?branch=master )](https://buildkite.com/solana-labs/solana/builds?branch=master)
[![codecov ](https://codecov.io/gh/solana-labs/solana/branch/master/graph/badge.svg )](https://codecov.io/gh/solana-labs/solana)
2020-04-09 11:06:09 -07:00
# Building
2018-02-15 15:09:11 -08:00
2020-04-09 11:06:09 -07:00
## **1. Install rustc, cargo and rustfmt.**
2018-02-15 15:09:11 -08:00
```bash
$ curl https://sh.rustup.rs -sSf | sh
2018-02-16 09:38:12 -08:00
$ source $HOME/.cargo/env
2019-05-19 18:41:15 -07:00
$ rustup component add rustfmt
2018-02-15 15:09:11 -08:00
```
2021-09-07 13:01:51 -07:00
When building the master branch, please make sure you are using the latest stable rust version by running:
2018-05-02 16:38:09 -07:00
```bash
$ rustup update
```
2021-09-07 13:01:51 -07:00
When building a specific release branch, you should check the rust version in `ci/rust-version.sh` and if necessary, install that version by running:
```bash
$ rustup install VERSION
```
Note that if this is not the latest rust version on your machine, cargo commands may require an [override ](https://rust-lang.github.io/rustup/overrides.html ) in order to use the correct version.
2022-10-10 19:17:15 -07:00
On Linux systems you may need to install libssl-dev, pkg-config, zlib1g-dev, protobuf etc.
2018-09-04 20:41:11 -07:00
2022-10-10 19:17:15 -07:00
On Ubuntu:
2018-07-02 10:22:37 -07:00
```bash
2020-02-08 14:45:07 -08:00
$ sudo apt-get update
2022-05-20 14:13:00 -07:00
$ sudo apt-get install libssl-dev libudev-dev pkg-config zlib1g-dev llvm clang cmake make libprotobuf-dev protobuf-compiler
2018-07-02 10:22:37 -07:00
```
2022-10-10 19:17:15 -07:00
On Fedora:
```bash
$ sudo dnf install openssl-devel systemd-devel pkg-config zlib-devel llvm clang cmake make protobuf-devel protobuf-compiler perl-core
```
2020-04-09 11:06:09 -07:00
## **2. Download the source code.**
2018-02-15 15:09:11 -08:00
```bash
2018-03-27 15:16:27 -07:00
$ git clone https://github.com/solana-labs/solana.git
$ cd solana
2018-02-15 15:09:11 -08:00
```
2020-04-09 11:06:09 -07:00
## **3. Build.**
2018-12-14 15:55:58 -08:00
```bash
2022-11-14 12:08:56 -08:00
$ ./cargo build
2018-12-14 15:55:58 -08:00
```
2020-04-09 11:06:09 -07:00
# Testing
2018-02-16 09:38:12 -08:00
2020-04-09 10:58:42 -07:00
**Run the test suite:**
2018-02-15 15:09:11 -08:00
```bash
2022-11-14 12:08:56 -08:00
$ ./cargo test
2018-02-15 15:09:11 -08:00
```
2018-02-16 09:38:12 -08:00
2020-04-09 11:06:09 -07:00
### Starting a local testnet
2024-01-03 06:06:06 -08:00
Start your own testnet locally, instructions are in the [online docs ](https://docs.solanalabs.com/clusters/benchmark ).
2018-11-06 07:06:36 -08:00
2020-11-10 09:03:57 -08:00
### Accessing the remote development cluster
2024-01-03 06:06:06 -08:00
2020-11-10 09:03:57 -08:00
* `devnet` - stable public cluster for development accessible via
2024-01-03 06:06:06 -08:00
devnet.solana.com. Runs 24/7. Learn more about the [public clusters ](https://docs.solanalabs.com/clusters )
2020-02-06 12:19:30 -08:00
2020-04-09 11:06:09 -07:00
# Benchmarking
2018-02-16 09:38:12 -08:00
2021-12-20 22:50:36 -08:00
First, install the nightly build of rustc. `cargo bench` requires the use of the
2019-03-04 09:00:52 -08:00
unstable features only available in the nightly build.
2018-02-16 09:38:12 -08:00
```bash
$ rustup install nightly
```
Run the benchmarks:
```bash
2019-03-04 09:00:52 -08:00
$ cargo +nightly bench
2018-02-16 09:38:12 -08:00
```
2018-04-04 08:26:32 -07:00
2020-04-09 11:06:09 -07:00
# Release Process
2018-11-28 16:48:27 -08:00
The release process for this project is described [here ](RELEASE.md ).
2018-08-16 20:48:11 -07:00
2020-04-09 11:06:09 -07:00
# Code coverage
2018-04-04 08:26:32 -07:00
2018-12-17 10:11:02 -08:00
To generate code coverage statistics:
2018-04-04 08:26:32 -07:00
```bash
2018-12-17 10:11:02 -08:00
$ scripts/coverage.sh
$ open target/cov/lcov-local/index.html
2018-04-04 08:26:32 -07:00
```
2018-06-18 16:36:37 -07:00
2018-04-04 08:26:32 -07:00
Why coverage? While most see coverage as a code quality metric, we see it primarily as a developer
productivity metric. When a developer makes a change to the codebase, presumably it's a *solution* to
some problem. Our unit-test suite is how we encode the set of *problems* the codebase solves. Running
the test suite should indicate that your change didn't *infringe* on anyone else's solutions. Adding a
test *protects* your solution from future changes. Say you don't understand why a line of code exists,
try deleting it and running the unit-tests. The nearest test failure should tell you what problem
was solved by that code. If no test fails, go ahead and submit a Pull Request that asks, "what
problem is solved by this code?" On the other hand, if a test does fail and you can think of a
better way to solve the same problem, a Pull Request with your solution would most certainly be
welcome! Likewise, if rewriting a test can better communicate what code it's protecting, please
send us that patch!