Hi,
sending again, accidentally sent from personal email first time and it's
stuck somewhere.
I would like to introduce new USE_EXPAND in profiles for rusts
3 consumers in the tree:
dev-lang/rust
dev-lang/rust-bin
sys-devel/rust-std
and maybe virtual, but not sure yet, may be required for firefox.
The idea:
Rust supports building as many targets as one wants, as long as C
toolchan can do it and matching llvm target is enabled on rust or llvm.
There are some special rust targets that require same host toolchain but
are treated like separate targets in rust.
For example x86_64-unknown-linux-gnu target is primary on amd64,
but on multilib profiles we can easily enable i686-unknown-linux-gnu
target and it will just work (that's how multilib in rust works now)
Another example is arm:
armv7-unknown-linux-gnueabihf is primary toolchain.
but rust supports additional target thumbv7neon-unknown-linux-gnueabihf,
which requires exactly same host toolchain, but is capable of emitting
thumb-neon binaries. This is required by firefox if --enable-neon is
passed in firefox build.
Another example: ppc64
We can easily build both ppc64 and ppc64le targets in a single bootstrap
with host toolchain, and rust will support emitting code for both endians.
Another example: musl
On musl we need 1 extra target with gentoo vendor field.
So installing both
x86_64-unknown-linux-musl
x86_64-gentoo-linux-musl
will be very easy, as both targets use same C toolchain, but slightly
different settings.
And last, but not the least, it allows cross support if matching
toolchain is installed (tested with crossdev)
A user can unmask the following targets on amd64
rust_targets_thumbv7neon-unknown-linux-gnueabihf
rust_targets_armv7-unknown-linux-gnueabihf
And as long as they have /usr/armv7a-unknown-linux-gnueabihf toolchain
available at build time, and llvm_targets_ARM enabled, rust will
bootstrap itself in a way that it will be able to emit code for any of 3
targets enable. This is optional opt-in functionality.
And just to clarify, native host toolchain is not going to be a
use-expand, at least that's how I imagine it now.
Native target matching CHOST is always build without any flags, and is
the default target for rust.
But I may re-evaluate it and introduce requirements like
abi_x86_64?? ( rust_targets_x86_64-unknown-linux-gnu )
abi_x86_32? ( rust_targets_i686-unknown-linux-gnu )
for multilib profiles.
and something like this for non-multilib arches.
ppc64? ( ||
rust_targets_powerpc64le-unknown-linux-gnu
rust_targets_powerpc64-unknown-linux-gnu
)
for example, similar to as llvm does with LLVM_TARGETS.
Of course default targets will be use-forced via profiles.
But if possible I'd avoid it.
Proof of concept exists (without using expand flags for now) in both
rust and rust-bin ebuilds. Multilib is implemented that way and has been
working great for more than a year, also experimental cross support in
rust implemented that way, and users are already able to define as many
targets as they want, but it feels hacky and I would like to move
forward to targets approach and make it trackable via flags, and not
magic variables nobody knows about.
Initial rollout will require a bit of arch profile masking (like llvm
does it) and maybe new eclass to reduce boilerplate code in ebuilds, but
nothing to complex.
WDYT?
tracking bug https://bugs.gentoo.org/747760
cross bugs:
https://bugs.gentoo.org/679878
https://bugs.gentoo.org/680652
https://bugs.gentoo.org/689336
Regards, Georgy.
