Hi,
We've switched over to a "new" build system -- which is largely a
copy-and-modify job on the old one -- that requires a slight change to
the way you build and use rustboot, rustc and such.
Previously you would do "make" in the src/ subdirectory and it would
build. We're removing that Makefile shortly. The new scheme is a
"configure; make" combo that behaves more-like what people expect.
We've done this for a few reasons:
- The new scheme supports -- and I strongly recommend -- out-of-tree
builds. These are useful for keeping build state and source state
untangled, as well as having multiple different configurations "wired
up" in a persistent state on disk, to build different variants (say:
profiling, debugging, etc.)
- The new scheme supports moving some configuration issues into
"configure"-time, which means the resultant "make" command starts
actually doing useful work faster (when re-invoking multiple times,
say). On win32, where fork is abysmally slow, this is quite noticeable.
- The new scheme is more familiar to newcomers and should permit
better interaction with package managers, when the time comes.
- Along the way, I took the opportunity (of having time to write a
makefile anew) to add support for multi-stage building. Or depending on
how you look at it, this was the one thing I *had* to do, and splitting
configuration out just came along for the ride.
That is: what was the "rustc" target has becomeo the "stage0/rustc"
target, and directories are made in $builddir for stage1 and stage2 as
well. This is necessary for bootstrapping, where we're going to have
rustc building itself regularly, in multiple passes, and checking for
convergence. Presently every 'make' run will now do:
- ocamlc builds boot/rustboot
- boot/rustboot builds boot/libstd.so
- boot/rustboot builds stage0/rustc
- stage0/rustc builds stage0/libstd.so
This will increase build times, obviously, since the second libstd build
is now part of the normal build. Build times will also increase when we
have stage1 and stage2 building (post-bootstrap), but times should come
back down a bit once we get optimizations enabled, and start
profiling-and-shaving, and have thrown out boot/rustboot and attendant
slow stage0/rustc. Eventually stage0/rustc will be fetched from an
archival server holding snapshots of stage1/rustc.
So: practical adaptations required on your part:
- Edit Makefile.in and configure, not src/Makefile (the latter will
be removed soon)
- Set your LD_LIBRARY_PATH or DYLD_LIBRARY_PATH to
$builddir/rt:$builddir/rustllvm:$builddir/stage0
in order to run stage0/rustc-compiled binaries. Set it to:
$builddir/rt:$builddir/rustllvm:$builddir/stage1
in order to run stage1/rustc-compiled binaries.
And so on. Feel free to ask questions here or on the list if any of this
is confusing.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
