[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: Re: [gentoo-dev] Add rust eclass to support multi-target compilation
From: Dirkjan Ochtman <djc () gentoo ! org>
Date: 2018-07-31 13:11:11
Message-ID: CAKmKYaDVGoGARVwQryhdW95X+MLdkQFbvsFoCzs-Sf0EF=OiVg () mail ! gmail ! com
[Download RAW message or body]
On Tue, Jul 31, 2018 at 12:03 PM Luca Barbato <lu_zero@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
[Attachment #3 (text/html)]
<div dir="ltr">On Tue, Jul 31, 2018 at 12:03 PM Luca Barbato <<a \
href="mailto:lu_zero@gentoo.org">lu_zero@gentoo.org</a>> wrote:<br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">> As far as I know, the Rust \
ecosystem is largely bimodal: stuff is either<br> > compatible with stable and \
later, or it works only on nightly. It seems<br> > very rare that code is actually \
tied to a particular Rust release and does<br> > not compile against latest Rust \
stable. (Upstream actually promises they<br> > won't break code except in case \
they need to fix a soundness issue in the<br> > compiler.) So instead of building \
this whole target infrastructure (which<br> > is definitely needed for something \
like Python or Ruby), we should be able<br> > to just work with stable and nightly \
slots, and ebuilds can depend on those.<br> <br>
This is true until you do not want to use libsyntax and other<br>
compiler-specific libraries.<br>
<br>
Because of the enforced ABI-randomness, what you built against stable<br>
must be rebuilt on stable.1, making those libraries non-shared might be<br>
a topic.<br></blockquote><div><br></div><div>I'm not sure what you mean here, can \
you give an example?<br></div><div> <br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Upstream \
is also very clearly packaging their core tooling as a single<br> > package made \
up of a number of components, and these are distributed and<br> > compiled \
together in common usage on other platforms (with the rustup<br> > tooling). That \
also means they are tightly coupled -- for example, rustfmt<br> > can change \
formats over time, and CI that checks formatting will need to<br> > align with \
whatever the current stable Rust version of rustfmt is.<br> <br>
Actually rustfmt is interesting since it does use libsyntax and<br>
depending on which project you may have to use the nightly rustfmt while<br>
targeting stable.<br></blockquote><div><br></div><div>Yeah, but in my suggested \
approach we would have slotted rustfmt.<br></div><div> <br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> > Installing the latest (nightly or beta) version of \
rustfmt while you have a<br> > stable Rust toolchain installed is thus not a good \
idea. As another<br> > example, cargo is now tagged as 0.28, but when passing \
--version it will<br> > report as 1.27.0 -- actually the Rust toolchain \
version.<br> <br>
Well it might be surprising, but for at least one project is actually<br>
required :)<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> > For these reasons, I think it would be better to align \
our Rust ebuilds<br> > with upstream and work with single ebuilds (dev-lang/rust \
and<br> > dev-lang/rust-bin) that install all the tools belonging to a \
particular<br> > version of the Rust toolchain.<br>
<br>
> What tools are installed can be customized<br>
> with USE flags, and the default install can be minimal (just rustc and<br>
> cargo, which you need to build packages anyway).<br>
<br>
So once you need bindgen you have to rebuild rustc and then you need<br>
clippy you build again rustc?<br></blockquote><div><br></div><div>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.<br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> And what happens once you have yet-another-tool using \
libsyntax, you add<br> it to the rustc ebuild and unleash a -r1 to the \
users?<br></blockquote><div><br></div><div>If upstream includes another tool in their \
distribution, we add that to the rust ebuild, yes.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div><br></div><div>Dirkjan<br></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic