On 06/07/2011 9:23 AM, Marijn Haverbeke wrote:
That is: stageN/bin contains everything needed-to-run stageN/bin, whereas
stageN/<arch>/lib contains everything needed-by-programs-produced-by stageN.
So far, so good. What I'm objecting to is using the libstd.so
*distributed in the snapshot* to link with stage1/rustc. If we do a
little creative directory shuffling, couldn't we make stage0/rustc
link against a libstd.so other than stage0/lib/libstd.so, and have the
make cycle start by building that lib from the current sources?
Hmm. I believe this is what I used to have it do, now that you mention
it this way, before we changed to the current arrangement. We changed it
for the sake of ... trying to reduce cross-directory dependencies. But
didn't accomplish that anyways. I remain confused about the correct order.
But yes, it does seem sane that rather than copy
stage0/<arch>/lib/libstd.so to stage1/bin, we could
recompile-from-source at that step; subsequent steps would obviously
make no difference (as stage1/lib/<arch>/libstd.so would be
bit-identical to stage2/bin/libstd.so whether we compile from workspace
or copy).
That would make stage1 and later able to use code from the working
directory without re-snapshotting. I think. I'm at least willing to try
that when we reshuffle things.
would already be enough to make extending the standard lib
non-painful. The subject of this thread suggests I care about the
actual paths, which is actually not what I was trying to get at. I
just care about not being stuck depending on the stdlib from the last
snapshot.
I realize that. Nobody wants more snapshots than necessary: I pay a bill
every month for s3 storage of them, after all :)
I am trying to arrive at a structure that simultaneously accommodates:
- The library path rules of 3 platforms' linkers and loaders
- Self-modification from snapshots
- Cross compilation to multiple targets
- Minimal numbers of snapshots for compatible changes
- Support for incompatible changes via "half-way" snapshots
- Arrival at a fixpoint in a single directory we can tar up
Balancing all these is a bit of careful work. I appreciate the ongoing
pressure to "get it right", but I'm absolutely on your side. I just ...
find that every strategy looks very similar and it's easy to go around
in circles. We've changed the structure a couple times already. I want
to arrive at a structure that works long-term.
> Also, once we split the compiler into more than one crate, I guess the
> extra crates will be compiled and linked in a way similar to the
> standard lib. Even if you consider having to snapshot after making a
> change to the standard lib acceptable for some masochistic reason, I
> hope you'll still see how having to do snapshot acrobatics when making
> a change that spans multiple of the compiler-related crates is going
> to reduce our productivity by an order of magnitude.
There's no need to use language like this; I'm not *intentionally*
trying to defeat productivity or inflict extra pain on the development
process. Quite the opposite: I now spend *all day* working on various
attempts at productivity-enhancement for the group; you may have noticed
I'm not writing much code lately. It's all fussy infrastructure work,
because I know how important it is to remove productivity barriers.
I didn't think what you were asking for was possible. But you raise a
valid point that it may well be if compilation order changes. I'm happy
to try that and see. So far we ... seem to keep getting surprised about
some detail of self-hosting that we didn't anticipate in the previous
arrangement. So we'll try again.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
