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.
Niko
On 12/14/11 8:34 PM, Brian Anderson wrote:
----- Original Message -----
From: "Niko Matsakis"<[email protected]>
To: [email protected]
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
using
the runtime sources that we compile out of the user's directory. As
the
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'.
-Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
