Switch the build process to using Rust's new build system called
rustbuild. At the same time stop using jemalloc on all platforms and
switch to the system allocator since that was simplier to do.
We'll need the prior version of cargo to boot strap ourselves going
forward so include the version info so we can support multiple versions
in the tree.
rustbuild is a cargo based way to build Rust but all of our helper bits
in cargo.bbclass would create a chicken/egg issue with dependencies
since we pull down pre-built binaries and use those for boot strapping.
Generate the Cargo recipe with cargo-bitbake instead of having a
handcrafted recipe. This should make future version bumps easier.
Three known issues:
- license checksum of the Apache license is a generateme value
due to the license file having a difference name then what's in
Cargo.toml.
- branch= value was wrong for tags. Pointed to HEAD instead of the
branch that the underlying tag commit came from.
- Use https protocol when the repo is publicly accessible.
There was a bbnote that showed the path to the rustc and cargo binaries
being used but this was not necessarily correct since it didn't use the
exact variables used.
For similar reasons to the C and linker wrappers, using rustbuild
requires a C++ wrapper to ensure that the right flags that Yocto needs
are passed to the underlying compiler.
Technically these dependencies change between versions. It just happens
that these two versions didn't change the dependencies but future
versions will so preemptively make the adjustment.
The path to the rust source changes from 1.15 so preemptively make
changes to prepare for that.
Signed-off-by: Derek Straka <derek@asterius.io>
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
The crate_hash flag is no longer accepted on rust 1.14. Additionally,
due to the use of wrapper scripts by cargo, we were no longer able to
link correctly due to some link flags getting dropped. Fix that as well
The way LLVM builds its native utilities is not safe (it runs a
recursive cmake in the same work directory as the main instance). To
prevent those instances from stepping on each other, we'll build the two
native utilities separately before starting the main build.
Fixes issue #143
This is a fast case if the slave has a local checkout available so that
it doesn't have to do a full clone. The check unfortunately didn't take
into account all cases and failed on the new slave.
