[gentoo-dev] RFC: introduce RUST_TARGETS use-expand (take2)

[gentoo-dev] RFC: introduce RUST_TARGETS use-expand (take2)

[Georgy Yakovlev]

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.