Prysm is go project with many complicated dependencies, including some c++ based libraries. There are two parts to Prysm's dependency management. Go modules and bazel managed dependencies. Be sure to read Why Bazel? to fully understand the reasoning behind an additional layer of build tooling via Bazel rather than a pure "go build" project.
The Prysm project officially supports go modules with some caveats.
Given some of Prysm's c++ dependencies have very complicated project structures which make building difficult or impossible with "go build" alone. Additionally, building c++ dependencies with certain compilers, like clang / LLVM, offer a significant performance improvement. To get around this issue, c++ dependencies have been precompiled as linkable archives. While there isn't necessarily anything bad about precompiled archives, these files are a "blackbox" which a 3rd party author could have compiled anything for this archive and detecting undesired behavior would be nearly impossible. If your risk tolerance is low, always compile everything from source yourself, including complicated c++ dependencies.
Recommendation: Use go build only for local development and use bazel build for production.
One key advantage of Bazel over vanilla go build is that Bazel automatically (re)builds generated
pb.go files at build time when file changes are present in any protobuf definition file or after
any updates to the protobuf compiler or other relevant dependencies. Vanilla go users should run
the following scripts often to ensure their generated files are up to date. Further more, Prysm
generates SSZ marshal related code based on defined data structures. These generated files must
also be updated and checked in as frequently.
./scripts/update-go-pbs.sh
./scripts/update-go-ssz.shRecommendation: Use go build only for local development and use bazel build for production.
When Prysmatic Labs builds production binaries, they use the "release" configuration of bazel to compile with several compiler optimizations and recommended production build configurations. Additionally, the release build properly stamps the built binaries to include helpful metadata about how and when the binary was built.
Recommendation: Use go build only for local development and use bazel build for production.
bazel build //beacon-chain --config=release- Add your dependency as you would with go modules. I.e.
go get ... - Run
gazelle update-repos -from_file=go.modto update the bazel managed dependencies.
Example:
go get github.com/prysmaticlabs/[email protected]
bazel run //:gazelle -- update-repos -from_file=go.mod -to_macro=deps.bzl%prysm_deps -prune=trueThe deps.bzl file should have been updated with the dependency and any transitive dependencies.
Do NOT add new go_repository to the WORKSPACE file. All dependencies should live in deps.bzl.
To enable conditional compilation and custom configuration for tests (where compiled code has more
debug info, while not being completely optimized), we rely on Go's build tags/constraints mechanism
(see official docs on build constraints).
Therefore, whenever using go test, do not forget to pass in extra build tag, eg:
go test ./beacon-chain/sync/initial-sync -tags develop