Gentoo Archives: gentoo-dev

From: Georgy Yakovlev <gyakovlev@g.o>
To: gentoo-dev@l.g.o
Cc: rust@g.o
Subject: [gentoo-dev] RFC: introduce RUST_TARGETS use-expand (take2)
Date: Sun, 11 Oct 2020 03:32:18
1 Hi,
3 sending again, accidentally sent from personal email first time and it's
4 stuck somewhere.
6 I would like to introduce new USE_EXPAND in profiles for rusts
7 3 consumers in the tree:
8 dev-lang/rust
9 dev-lang/rust-bin
10 sys-devel/rust-std
11 and maybe virtual, but not sure yet, may be required for firefox.
13 The idea:
14 Rust supports building as many targets as one wants, as long as C
15 toolchan can do it and matching llvm target is enabled on rust or llvm.
17 There are some special rust targets that require same host toolchain but
18 are treated like separate targets in rust.
19 For example x86_64-unknown-linux-gnu target is primary on amd64,
20 but on multilib profiles we can easily enable i686-unknown-linux-gnu
21 target and it will just work (that's how multilib in rust works now)
23 Another example is arm:
25 armv7-unknown-linux-gnueabihf is primary toolchain.
26 but rust supports additional target thumbv7neon-unknown-linux-gnueabihf,
27 which requires exactly same host toolchain, but is capable of emitting
28 thumb-neon binaries. This is required by firefox if --enable-neon is
29 passed in firefox build.
31 Another example: ppc64
33 We can easily build both ppc64 and ppc64le targets in a single bootstrap
34 with host toolchain, and rust will support emitting code for both endians.
36 Another example: musl
38 On musl we need 1 extra target with gentoo vendor field.
39 So installing both
40 x86_64-unknown-linux-musl
41 x86_64-gentoo-linux-musl
42 will be very easy, as both targets use same C toolchain, but slightly
43 different settings.
45 And last, but not the least, it allows cross support if matching
46 toolchain is installed (tested with crossdev)
47 A user can unmask the following targets on amd64
48 rust_targets_thumbv7neon-unknown-linux-gnueabihf
49 rust_targets_armv7-unknown-linux-gnueabihf
51 And as long as they have /usr/armv7a-unknown-linux-gnueabihf toolchain
52 available at build time, and llvm_targets_ARM enabled, rust will
53 bootstrap itself in a way that it will be able to emit code for any of 3
54 targets enable. This is optional opt-in functionality.
56 And just to clarify, native host toolchain is not going to be a
57 use-expand, at least that's how I imagine it now.
58 Native target matching CHOST is always build without any flags, and is
59 the default target for rust.
60 But I may re-evaluate it and introduce requirements like
62 abi_x86_64?? ( rust_targets_x86_64-unknown-linux-gnu )
63 abi_x86_32? ( rust_targets_i686-unknown-linux-gnu )
65 for multilib profiles.
67 and something like this for non-multilib arches.
69 ppc64? ( ||
70 rust_targets_powerpc64le-unknown-linux-gnu
71 rust_targets_powerpc64-unknown-linux-gnu
72 )
74 for example, similar to as llvm does with LLVM_TARGETS.
75 Of course default targets will be use-forced via profiles.
76 But if possible I'd avoid it.
79 Proof of concept exists (without using expand flags for now) in both
80 rust and rust-bin ebuilds. Multilib is implemented that way and has been
81 working great for more than a year, also experimental cross support in
82 rust implemented that way, and users are already able to define as many
83 targets as they want, but it feels hacky and I would like to move
84 forward to targets approach and make it trackable via flags, and not
85 magic variables nobody knows about.
88 Initial rollout will require a bit of arch profile masking (like llvm
89 does it) and maybe new eclass to reduce boilerplate code in ebuilds, but
90 nothing to complex.
92 WDYT?
94 tracking bug
96 cross bugs:
101 Regards, Georgy.