The old cargo.bbclass had no users in meta-rust and had lots of
problems (not least of which was lots of duplicated lines with
cargo_util.bbclass). Delete the old cargo.bbclass and replace it
entirely wiht cargo_util
It's forbidden to access the network during the build phase in bitbake.
Since this version of cargo does not yet support source-replacement, we
must patch out the behavior instead.
The local registry is a more future-proof way to prevent cargo from
accessing the network during the build. Unfortunately, this is only
used during the build of cargo-native for now. The snapshot used while
building cargo-native supports using a local registry ("source
replacement") however the version of cargo supported by rust 1.10 does
not.
Until we can build a new-enough version of cargo that supports
source-replacement, we'll have to patch cargo directly to prevent it
from accessing the network. Once we do have a new-enough cargo, we can
stop populating cargo_home/registry and only create cargo_registry.
Instead of building a full compiler, we can use rust-native to
cross-compile. All we need is a cross-compiled standard library, which
libstd-rs builds, and a compiler spec file. rust-cross is now just used
to generate the json spec file for cross-compiling, which is naturally
much faster.
This is the compatible version shipped with Rust 1.10.0. Use the git
hash from the release TOML file so there is no ambiguity.
Update git2 and curl dependencies and patches to match those in
Cargo.lock.
Rust does something fairly different than in 1.7. Instead of just
expecting the tarball to exist, it either expects an already extracted
and ready toolchain, or else it does everything itself.
To work with that, we'll always pass --use-local-rust to ./configure so
that bootstrap.py doesn't try to download anything. We'll either
download and setup a snapshot ourselves, or use the system rust, based
on PACKAGECONFIG[local-rust] as before
The oe-core/poky change 'base.bbclass wipe ${S} before unpacking
source' (poky: a56fb90dc3805494eeaf04c60538425e8d52efc5, oe-core:
eccae514b71394ffaed8fc45dea7942152a334a1) wipes ${S} in do_unpack prior
to unpacking. This breaks our shared source as we set ${S} to the shared
location, and don't actually unpack anything (the result is we try to
build rustc without any source code, which fails predictably)
Avoid this by clearing do_unpack[cleandirs].
At the same time take pieces of gcc-shared-source.inc and note how & why
we differ from how gcc operates.
This is a bit of a hack, and only happens to work because we know the
exact method that do_unpack uses to clear ${S}, and using python()
happens to get called at the "right time".
Steven Walter
Steven Walter
Tyler Hall
Doug Goldstein
Derek Straka
Cody Schafer