* Convert to new override syntax
This is the result of automated script (0.9.0) conversion:
oe-core/scripts/contrib/convert-overrides.py .
converting the metadata to use ":" as the override character instead of "_".
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* Manually fix the conversion
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* layer.conf: Update layer compatibility with only dunfell and newer.
Add honister to mark the layers as compatible with honister now that it uses
the new override syntax.
Drop zeus and older which are missing a support for newer override syntax which
was backported only to 1.46 branch (used by dunfell) and newer, e.g.:
https://git.openembedded.org/bitbake/commit/?h=1.46&id=c5418eae56cc50dbae7951c055434a0c456c53a4
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* CI: use YOCTO_BRANCH instead of yocto-${YOCTO_VERSION} for poky checkout
* using latest revision in branch is often better than sticking to
some point releases
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* CI: switch to hardknott branch
* gatesgarth is already EOL, better to use something supported
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
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.
RUSTFLAGS is used by Cargo and always passed to the compiler. Put our
non-standard crate_hash argument there because it is required for
reproducible builds.
Add the rpath option to avoid having to patch Cargo.toml for this and
remove the function that does so.
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
rust-bin.bbclass now only contains what is necessary to build crates
using the rust compiler directly and rust.bbclass contains information
shared between rust-bin and cargo.
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
This should eliminate the problems that have been seen when bitbake
rebuilds part of the rust stack (due to missing sstate) and ends up
getting hash mismatches. Unlike rust's internally generated hash, ours
is guaranteed to be stable.
