[rust-dev] runtime libraries and stage1
niko at alum.mit.edu
Wed Dec 14 20:47:50 PST 2011
Your point about std/core is well taken and basically convinces me that
my idea is not good. It would definitely still be nice if there were a
way to "quarantine" the original runtime, but perhaps just preserving
the old definitions for a time is the best we can do.
If nothing else, we could make this a bit more automatic by having the
runtime functions "namespaced" with some sort of prefix, like "rust4_"
or what have you. Then when we make backwards incompatible changes, we
literally copy the entire runtime into a new subdirectory with a new
prefix ("rust5_"). We make changes liberally to rust5_ and delete
rust4_ once the new snapshot is in place. (In the compiler this prefix
would be automatically added, of course)
Such a system would also allow us to keep backwards compatibility with
binaries generated by older versions of the compiler, once Rust becomes
widely used and hugely popular. It's certainly not the smartest way to
handle that particular situation, though, as it would also lead to a
maintenance nightmare as there would be many versions of the same code
in the codebase.
That said, we do probably want to start thinking about how we will
version the runtime for backwards compatibility, and maybe we can use
whatever scheme we come up with to ease the bootstrapping pain as well.
On 12/14/11 8:34 PM, Brian Anderson wrote:
> ----- Original Message -----
>> From: "Niko Matsakis"<niko at alum.mit.edu>
>> To: rust-dev at mozilla.org
>> Sent: Wednesday, December 14, 2011 7:00:33 PM
>> Subject: [rust-dev] runtime libraries and stage1
>> So, if I am not mistaken, we currently execute the stage1 compiler
>> the runtime sources that we compile out of the user's directory. As
>> stage1 binary is built using the snapshot, this doesn't seem quite
>> right: we ought to be executing it using the snapshot runtime. The
>> stage2 and stage3 binaries, then, ought to execute using the runtime
>> from the user's directory.
> With Rust having to bootstrap itself there will always be some situations that are difficult to make incompatible changes. The current arrangement is definitely the best we've had so far (in the past things have been occassionally truly frustrating), so I'm ambivalent about this. And I like that the current snapshot only requires the bare minimum of host artifacts, no target artifacts.
> With this change it will be easy to modify upcalls. On the other hand, any time std or core need to modify a runtime interface it will require creating temporary runtime methods, snapshotting, etc. So maybe we also snapshot core& std for each target. Now you promote the stage0 target snapshots to stage1. At this point we've reproduced the existing stage0 problems, but are calling them stage1.
> Intrinsics and libmorestack have similar dependencies on the runtime as std and core, though they change rarely.
> I'm totally fine with trying, but I don't think there's anything we can do that will be definitively 'right'.
More information about the Rust-dev