I just realized that all this work on getting a good naming scheme for
Rust libraries will probably address backwards compatibility for the
runtime as well...? In other words, we won't need any sort of name
mangling scheme because we'll ship multiple libraries and the older code
will select the older library (assuming the runtime is not statically
compiled in, which it may well be anyhow). Anyway, I'm sure this has
been discussed before, and I'm just coming late to the party, so I'll
stop writing e-mail and get back to what I was doing...
Niko
On 12/14/11 8:47 PM, Niko Matsakis wrote:
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
