prysm-pulse/tools/cross-toolchain/README.md
prylabs-bulldozer[bot] e2a6f5a6ea
First cut at multi-arch cross compiling toolchain (#4945)
*  PRYSM-2849 first cut at multi-arch cross compiling toolchain.  currently supports arm64 and amd64 via docker cross compiler image
* picky linter
* some readme cleanup
* remove arm 8.2 revision for arm64 builds (cortex a72 is ARMv8.0-A)
remove arm32 toolchain from multiarch dockerfile
* remove extranous WORKSPACE entries
* add docker remote execution configs for amd64 and arm64
* add osx bazelrc configs
* working osx toolchain
* update readme
* cleanup for amd, arm and osx cross before beginning windows
* initial stab at mingw windows cross
* add docker target for windows_amd64 and update readme for cross-compiling
* little more cleanup for readability
* Check in generated RBE. Still tweaking config but linux amd64 -> linux amd64 on RBE works OK. Cross compile does not work properly in RBE yet.
* fix
* update image
* Making some progress
* delete artifacts
* Working build
* Add remote config
* remove some things I added to README
* Tidy
* Update readme
* remove 2 commented lines
* buildifer
* Merge pull request #1 from prysmaticlabs/cross-compile-with-suburbandad

Cross compile with suburbandad
* Merge branch 'master' into clang-cross-compile
* buildifier on generated stuff
* Merge branch 'master' into clang-cross-compile
* Merge branch 'master' into clang-cross-compile
* Merge branch 'master' into clang-cross-compile
2020-03-05 16:59:56 +00:00

40 lines
3.2 KiB
Markdown

# Multiarch Cross Compiling Toolchain
## Toolchain suite
This package declares a c++ toolchain suite with cross compilers for targeting four platforms:
* linux_amd64
* linux_arm64
* osx_amd64
* windows_amd64
This toolchain suite describes cross compile configuration with a Dockerfile with the appropriate host dependencies. These toolchains can be used locally (see [caveats](#caveats)), [Remote Build Execution (RBE)](https://docs.bazel.build/versions/master/remote-execution.html), and in a docker sandbox (like RBE, but local).
### Cross compile target support
| target | linux_amd64 | linux_arm64 | osx_amd64 | windows_amd64 |
|----------|-------------------|------------------|-----------------|-----------------------|
| `//beacon-chain` | :heavy_check_mark: docker-sandbox and RBE, libkafka supported locally only | :heavy_check_mark: docker-sandbox and RBE, no libkafka support | :heavy_check_mark: docker-sandbox, no libkafka support | :heavy_check_mark: docker-sandbox, no libkafka support |
| `//validator`| :heavy_check_mark: docker-sandbox and RBE | :heavy_check_mark: docker-sandbox and RBE | :heavy_check_mark: docker-sandbox | :x: Doesn't work. [#5008](https://github.com/prysmaticlabs/prysm/issues/5008) |
The configurations above are enforced via pull request presubmit checks.
### Bazel config flag values
Use these values with `--config=<flag>`, multiple times if more than one value is defined in the table. Example: `bazel build //beacon-chain --config=windows_amd64_docker` to build windows binary in a docker sandbox.
| Config | linux_amd64 | linux_arm64 | osx_amd64 | windows_amd64 |
|----------|-------------------|------------------|-----------------|-----------------------|
| Local run | `linux_amd64` | `linux_arm64` | `osx_amd64` | `windows_amd64` |
| Docker sandbox | `linux_amd64_docker` | `linux_arm64_docker` | `osx_amd64_docker` | `windows_amd64_docker `|
| RBE (See [Caveats](#caveats)) | `linux_amd64` and `remote` | `linux_arm64` and `remote` | `osx_amd64` and `remote` | `windows_amd64` and `remote` |
### Caveats
There are a few caveats to each of these strategies.
- Local runs require clang compiler and the appropriate cross compilers installed. These runs should only be considered for a power user or user with specific build requirements. See the Dockerfile setup scripts to understand what dependencies must be installed and where.
- Docker sandbox is *slow*. Like really slow! The purpose of the docker sandbox is to test RBE builds without deploying a full RBE system. Each build action is executed in its own container. Given the large number of small targets in this project, the overhead of creating docker containers makes this strategy the slowest of all, but requires zero additional setup.
- Remote Build Execution is by far the fastest, if you have a RBE backend available. This is another advanced use case which will require two config flags above as well as additional flags to specify the `--remote_executor`. Some of these flags are present in the project `.bazelrc` with example values, but commented out.
- Building with libkafka (`--define kafka_enabled=true`) is not supported with docker-sandbox or RBE at this time. Likely due to missing cmake dependencies in the builder image or lack of configuration via toolchains.