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

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

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

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

Reply via email to