On Monday, March 21, 2016 at 9:43:24 AM UTC-7, Petr Cerny wrote: > Chris Peterson wrote: > > On 3/20/16 3:04 AM, Henri Sivonen wrote: > >> On Sat, Mar 19, 2016 at 2:27 PM, <cosinusoida...@gmail.com> wrote: > >>> > On Thursday, 17 March 2016 12:23:32 UTC, Henri Sivonen wrote: > >>>> >> (rustc originally bootstrapped with OCaml, but > >>>> >> building the whole history of Rust from the OCaml days to present > >>>> >> every time Fedora builds Firefox seems excessively impractical.) > >>> > > >>> > Out of interest, would that actually involve building every single > >>> > Linux snapshot from > >>> > https://github.com/rust-lang/rust/blob/master/src/snapshots.txt in > >>> > sequence? All 319 of them? > >> Presumably, yes, if you want to bootstrap from OCaml. Maybe you could > >> skip some snapshots, but you don't know which ones in advance. > >> Fortunately, e.g. the Fedora policy doesn't require bootstrapping all > >> the way from OCaml. > > > > How does Debian bootstrap other compilers like Go that are partially > > self-hosted? Would a Rust compiler written in C/C++ (e.g. generated by > > an LLVM back-end that emitted C/C++ code?) avoid the bootstrap policy > > requirements? > > That would definitely help (and not just for Debian), since > bootstrapping as far as possible is a generally preferred direction on > Linux, with the only exception of the basic toolchain (binutils, GCC), > libc and couple more packages that form a basic system (shell, make). > That is: you take a minimal working system, recompile new versions of > the packages with those from older release, then use the new minimal > system to build anything else. > > If you can get sources that will allow building current rustc within say > 3 build cycles, i.e.: > > [C sources]---(C compiler)-->[rustc-intermediate] > > [Rust sources]---(rustc-intermediate)-->[rustc-current] > > [Rust sources]---(rustc-current)-->[rustc-current] > > it will be just fine. Obviously 2 cycles would be nicer, but this even > with one added layer in between is manageable. If the distributed source > package contained both the rust sources and a bootstrapping compiler and > maybe even allowed building the final binary with a single command (a la > `[configure script]; make`) it would behave just like any other package. > > Actually, this would be pretty much what GCC does: it bootstraps itself > in three phases, with just one `make` command. And although the scale is > much longer, compiling for example GCC-5.3.0 with GCC
This is also what rustc does - it bootstraps off of itself. rustc is a self-hosting systems compiler comparable to gcc. Asking rustc to bootstrap off of yet another compiler is just kicking the can down the road. Eventually Rust wants to be in the same position as gcc, where distros have their own binary lineage and are bootstrapping their own compiler. If we were to put the effort into transpiling to C (or flat out writing a rust compiler in C) so that it could be recompiled it would just be an intermediate step until distros have their own bootstrap working. Bootstrapping off of transpiled C is not much different than bootstrapping off a binary blog. The C is not going to be readable. > > The problem is having to go through some 300 iterations (even if one > would probably do that only once on each distribution release). Which as > far as I understand - and please do correct me if I'm wrong - would be > the case (presumably because rustc's code is progressively using its own > new features). I don't think anybody is expecting this. And in any case it's so impracticable that it's impossible. Distros will pick some existing binary snapshot to trust and then bootstrap off their own binaries. > > From my point of view there are two options that would greatly help: > > 1) a bootstrapping rust compiler written in C that would work in a > small number of rounds as has been described above. It could as well be > C++, Python, Perl or whatever can be commonly found in distributions - > the lower the better to keep the dependency tree smaller. If this tool existed it would definitely help fill in the gaps. It would be a great amount of work to maintain. > > 2) a more stable rustc codebase - stable in the sense that a recompile > would only be necessary on the order of magnitude of ESR releases (note: > I'm writing this without any knowledge about current rustc compile > requirements). This would allow distributions to perform the long > iteration chain once and then update rustc only from time to time. > > Thanks > Kind regards > Petr > -- > Petr Cerny > Mozilla/OpenSSH maintainer for SUSE Linux _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
