Re: [gentoo-dev] Add rust eclass to support multi-target compilation

[Luca Barbato]

On 31/07/2018 09:35, Dirkjan Ochtman wrote:
> On Mon, Jul 30, 2018 at 5:02 PM gibix <gibix@××××××.net> 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.

> 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.

> 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 :)

> 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?

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?

Sorry, does not sound good.

lu