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 |