On Tue, Jul 31, 2018 at 12:03 PM Luca Barbato <lu_z...@gentoo.org> wrote:
> > As far as I know, the Rust ecosystem is largely bimodal: stuff is either > > compatible with stable and later, or it works only on nightly. It seems > > very rare that code is actually tied to a particular Rust release and > does > > not compile against latest Rust stable. (Upstream actually promises they > > won't break code except in case they need to fix a soundness issue in the > > compiler.) So instead of building this whole target infrastructure (which > > is definitely needed for something like Python or Ruby), we should be > able > > to just work with stable and nightly slots, and ebuilds can depend on > those. > > This is true until you do not want to use libsyntax and other > compiler-specific libraries. > > Because of the enforced ABI-randomness, what you built against stable > must be rebuilt on stable.1, making those libraries non-shared might be > a topic. > I'm not sure what you mean here, can you give an example? > > Upstream is also very clearly packaging their core tooling as a single > > package made up of a number of components, and these are distributed and > > compiled together in common usage on other platforms (with the rustup > > tooling). That also means they are tightly coupled -- for example, > rustfmt > > can change formats over time, and CI that checks formatting will need to > > align with whatever the current stable Rust version of rustfmt is. > > Actually rustfmt is interesting since it does use libsyntax and > depending on which project you may have to use the nightly rustfmt while > targeting stable. > Yeah, but in my suggested approach we would have slotted rustfmt. > > Installing the latest (nightly or beta) version of rustfmt while you > have a > > stable Rust toolchain installed is thus not a good idea. As another > > example, cargo is now tagged as 0.28, but when passing --version it will > > report as 1.27.0 -- actually the Rust toolchain version. > > Well it might be surprising, but for at least one project is actually > required :) > So what project is that, and what exactly does it require? At some point if your project requires very custom stuff maybe you should just build your own Rust. > > For these reasons, I think it would be better to align our Rust ebuilds > > with upstream and work with single ebuilds (dev-lang/rust and > > dev-lang/rust-bin) that install all the tools belonging to a particular > > version of the Rust toolchain. > > > What tools are installed can be customized > > with USE flags, and the default install can be minimal (just rustc and > > cargo, which you need to build packages anyway). > > So once you need bindgen you have to rebuild rustc and then you need > clippy you build again rustc? > Yes, it can be a pain, but I don't think "switching what auxiliary tools are installed" is the common scenario that we should optimize for necessarily. > And what happens once you have yet-another-tool using libsyntax, you add > it to the rustc ebuild and unleash a -r1 to the users? > If upstream includes another tool in their distribution, we add that to the rust ebuild, yes. I think there's a lot of value in aligning with upstream and with how something is distributed on other platforms, because this reduces friction for our users. Regards, Dirkjan
