1 |
Hi, |
2 |
|
3 |
sending again, accidentally sent from personal email first time and it's |
4 |
stuck somewhere. |
5 |
|
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. |
12 |
|
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. |
16 |
|
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) |
22 |
|
23 |
Another example is arm: |
24 |
|
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. |
30 |
|
31 |
Another example: ppc64 |
32 |
|
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. |
35 |
|
36 |
Another example: musl |
37 |
|
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. |
44 |
|
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 |
50 |
|
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. |
55 |
|
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 |
61 |
|
62 |
abi_x86_64?? ( rust_targets_x86_64-unknown-linux-gnu ) |
63 |
abi_x86_32? ( rust_targets_i686-unknown-linux-gnu ) |
64 |
|
65 |
for multilib profiles. |
66 |
|
67 |
and something like this for non-multilib arches. |
68 |
|
69 |
ppc64? ( || |
70 |
rust_targets_powerpc64le-unknown-linux-gnu |
71 |
rust_targets_powerpc64-unknown-linux-gnu |
72 |
) |
73 |
|
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. |
77 |
|
78 |
|
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. |
86 |
|
87 |
|
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. |
91 |
|
92 |
WDYT? |
93 |
|
94 |
tracking bug https://bugs.gentoo.org/747760 |
95 |
|
96 |
cross bugs: |
97 |
https://bugs.gentoo.org/679878 |
98 |
https://bugs.gentoo.org/680652 |
99 |
https://bugs.gentoo.org/689336 |
100 |
|
101 |
Regards, Georgy. |