Gentoo Archives: gentoo-dev

From: Dirkjan Ochtman <djc@g.o>
To: Luca Barbato <lu_zero@g.o>
Cc: Gentoo Development <gentoo-dev@l.g.o>, cardoe@g.o, alicef@g.o
Subject: Re: [gentoo-dev] Add rust eclass to support multi-target compilation
Date: Tue, 31 Jul 2018 13:11:32
Message-Id: CAKmKYaDVGoGARVwQryhdW95X+MLdkQFbvsFoCzs-Sf0EF=OiVg@mail.gmail.com
In Reply to: Re: [gentoo-dev] Add rust eclass to support multi-target compilation by Luca Barbato
1 On Tue, Jul 31, 2018 at 12:03 PM Luca Barbato <lu_zero@g.o> wrote:
2
3 > > As far as I know, the Rust ecosystem is largely bimodal: stuff is either
4 > > compatible with stable and later, or it works only on nightly. It seems
5 > > very rare that code is actually tied to a particular Rust release and
6 > does
7 > > not compile against latest Rust stable. (Upstream actually promises they
8 > > won't break code except in case they need to fix a soundness issue in the
9 > > compiler.) So instead of building this whole target infrastructure (which
10 > > is definitely needed for something like Python or Ruby), we should be
11 > able
12 > > to just work with stable and nightly slots, and ebuilds can depend on
13 > those.
14 >
15 > This is true until you do not want to use libsyntax and other
16 > compiler-specific libraries.
17 >
18 > Because of the enforced ABI-randomness, what you built against stable
19 > must be rebuilt on stable.1, making those libraries non-shared might be
20 > a topic.
21 >
22
23 I'm not sure what you mean here, can you give an example?
24
25
26 > > Upstream is also very clearly packaging their core tooling as a single
27 > > package made up of a number of components, and these are distributed and
28 > > compiled together in common usage on other platforms (with the rustup
29 > > tooling). That also means they are tightly coupled -- for example,
30 > rustfmt
31 > > can change formats over time, and CI that checks formatting will need to
32 > > align with whatever the current stable Rust version of rustfmt is.
33 >
34 > Actually rustfmt is interesting since it does use libsyntax and
35 > depending on which project you may have to use the nightly rustfmt while
36 > targeting stable.
37 >
38
39 Yeah, but in my suggested approach we would have slotted rustfmt.
40
41
42 > > Installing the latest (nightly or beta) version of rustfmt while you
43 > have a
44 > > stable Rust toolchain installed is thus not a good idea. As another
45 > > example, cargo is now tagged as 0.28, but when passing --version it will
46 > > report as 1.27.0 -- actually the Rust toolchain version.
47 >
48 > Well it might be surprising, but for at least one project is actually
49 > required :)
50 >
51
52 So what project is that, and what exactly does it require? At some point if
53 your project requires very custom stuff maybe you should just build your
54 own Rust.
55
56
57 > > For these reasons, I think it would be better to align our Rust ebuilds
58 > > with upstream and work with single ebuilds (dev-lang/rust and
59 > > dev-lang/rust-bin) that install all the tools belonging to a particular
60 > > version of the Rust toolchain.
61 >
62 > > What tools are installed can be customized
63 > > with USE flags, and the default install can be minimal (just rustc and
64 > > cargo, which you need to build packages anyway).
65 >
66 > So once you need bindgen you have to rebuild rustc and then you need
67 > clippy you build again rustc?
68 >
69
70 Yes, it can be a pain, but I don't think "switching what auxiliary tools
71 are installed" is the common scenario that we should optimize for
72 necessarily.
73
74
75 > And what happens once you have yet-another-tool using libsyntax, you add
76 > it to the rustc ebuild and unleash a -r1 to the users?
77 >
78
79 If upstream includes another tool in their distribution, we add that to the
80 rust ebuild, yes.
81
82 I think there's a lot of value in aligning with upstream and with how
83 something is distributed on other platforms, because this reduces friction
84 for our users.
85
86 Regards,
87
88 Dirkjan