* BB_NUMBER_THREADS is number of bitbake tasks running in parallel, not parallelization inside individual tasks * use oe.utils.parallel_make_argument to make sure it works even when people add e.g. "-l 10" in PARALLEL_MAKE * with the recent improvements for rust-native build time, I wanted to rerun some build time tests from https://github.com/shr-project/test-oe-build-time here are the results on AMD Threadripper 3970x with 128GB ram: BB is BB_NUMBER_THREADS PM is PARALLEL_MAKE TIME BB PM Description 20:50 * * zeus based build with 1.37 rust (BB/PM has no impact) 14:50 8 32,48,64 dunfell, 1.43 as ind2ff87ca55(PM has no impact, because bootstrap uses BB) 9:50 8 32,48,64 dunfell, 1.43 with this patch applied, it doesn't get faster after some threashold of PM 13:32 8 64 dunfell, 1.43 with this patch applied and "rust.inc: cut build time in half" (afcb58e5b9) reverted 13:30 8 64 dunfell, 1.43 with "rust.inc: cut build time in half" (afcb58e5b9) as well as "rust.inc: run bootstrap.py in parallel" (40a6bd8a8d) reverted to see if 1.43 builds faster without any meta-rust improvements compared to 1.37 94:47 1 64 dunfell, 1.43 as ind2ff87ca55(either something went wrong or explicit "-j 1" disables some parallelism done by default already 13:40 * * zeus based build with 1.39 rust (BB/PM has no impact) 10:50 8 64 zeus based build with 1.39 rust as proposed in jansa/new-zeus-branch 80:51 8 1 zeus based build with 1.39 rust as proposed in jansa/new-zeus-branch with "-j 1" PARALLEL_MAKE Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Introduction
This OpenEmbedded layer provides the rust compiler, tools for building packages (cargo), and a few example projects.
What works:
- Building
rust-nativeandcargo-native - Building Rust based projects with Cargo for the TARGET
- e.g.
rustfmtwhich is used by the CI system
- e.g.
-buildsdkand-crosssdkpackages
What doesn't:
- Using anything but x86_64 as the build environment
- rust (built for target) issue #81
What's untested:
- cargo (built for target)
Building a rust package
When building a rust package in bitbake, it's usually easiest to build with cargo using cargo.bbclass. If the package already has a Cargo.toml file (most rust packages do), then it's especially easy. Otherwise you should probably get the code building in cargo first.
Once your package builds in cargo, you can use cargo-bitbake to generate a bitbake recipe for it. This allows bitbake to fetch all the necessary dependent crates, as well as a pegged version of the crates.io index, to ensure maximum reproducibility.
NOTE: You will have to edit the generated recipe based on the comments contained within it
TODO
Pitfalls
- TARGET_SYS must be different from BUILD_SYS. This is due to the way Rust configuration options are tracked for different targets. This is the reason we use the Yocto triples instead of the native Rust triples. See rust-lang/cargo#3349.
Dependencies
On the host:
- Any
-syspackages your project might need must have RDEPENDs for the native library.
On the target:
- Any
-syspackages your project might need must have RDEPENDs for the native library.
Maintainer(s) & Patch policy
Open a Pull Request.
The master branch supports the latest master of poky. When poky creates releases, we will create a branch with the same name as the poky release. This release branch should always work with that poky release. Note that these release branches will typically be less tested than the master branch.
All new patches against rust, rust-llvm, and cargo must have referenced upstream issues or PRs opened or an explanation why the patch cannot be upstreamed. This cooresponds to the OpenEmbedded policy for other meta layers.
More info can be seen on the wiki.
Copyright
MIT OR Apache-2.0 - Same as rust