Simplify build directory structure.

[brson]

Our build directory contains too many files. Somebody who builds Rust for the first time is probably going to be interested in running rustc, but where to find it? Let's make it super simple.

This is about the directory structure of our build artifacts, not the source.

First we move the distracting "llvm", "rt", "rustllvm", "tmp" from the top of the build structure to under each target triple. We already build most of these things per target; they have just use a different directory structure than our Rust projects. Now only "config.mk", "config.stamp", "dl", "doc", "Makefile", and the target-triple-named output directories are at the top of the build structure.

Second we create a symlink called "out" that links to $(HOST_TRIPLE)/stage2. Now after you do a build you just type out/bin/rustc instead of x86_64-unknown-linux/stage2/bin/rustc.

[graydon]

I agree with moving the target artifacts into the per-target dirs. Not sure about the symlink; won't work on windows and it feels like just adding tangle to an already tangled structure. But I agree it's confusing to users. As are the multiple copies of everything! How do you make a multi-target cross-compiler less tangly? hmm

Actually .. is there a reason why we put everything in ${HOST_TRIPLE} right now? Do we support configuring with multiple simultaneous host triples in the same workspace? I don't think we do...

[brson]

Windows vista+ does apparently have symlinks, but I can understand that it might not be an improvement to add more directories.

We actually put every target into ${TARGET_TRIPLE}, one of them just happens to be the same as ${HOST_TRIPLE}. One thing we could do is use the name out when we are only building for one target.

In the long term, I think the the host/target division we have is not correct - what we call the host is actually the 'build' triple, what we call target triples are actually 'host' triples (we build compilers for these), and there's is a yet undiscovered 'target' triple for which we do not build a compiler.

[graydon]

Heh. You're talking about a Canadian Cross configuration ( http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross ) which, while I agree is a possible enhancement to our build system, I opted against when sketching out the current scheme on the basis that it was over-engineered for our needs at the time. You can usually work around it since most machines that can serve as host are similar-speed now and can also serve as build (and indeed, for our uses since we always want to test that the compiler on a given host still passes the testsuite, and that's the bottleneck, we wouldn't gain a lot by building on a different build machine and then copying the compiler over for testing, which is the sort of scenario the Canadian Cross was invented to address -- building a sparc-to-sparc toolchain from a fast x86 machine, say).

I guess we can make the "new" build system know about canadian cross, if you think it'll ever become an important config. It would at least let us get windows out of the loop for future developers (you could build your windows snapshots on linux and test them under wine). There's no wine-workalike for pretending you're on OSX yet, sadly.

[pnkfelix]

Visiting for bug triage, 2013 june 27.

I assume from graydon's last comment that we probably should not attempt to shoehorn a Canadian Cross configuration into the current Makefile-based infrastructure.

I personally would favor the symlink of out to ${TARGET_TRIPLE}/stage2, but at this point I have also gotten used to traversing the directory tree, so it is not a big deal for me either. (But this is not for us, its for the new users, right? A symlinked out is actually a great sign post for someone running ls -l.)

As for the revisions to the directory layout: should we try to put that in to both the Makefile based system and into the "new" build system. Or should we wait until the "new" build system is deployed (using the existing directory layout, so that people can switch between old and new while the kinks are worked out), and then post-kinks, we revise the directory layout?

[pnkfelix]

@alexcrichton Wait, is this actually finished now? There's still the second step of the symlink, right?

[alexcrichton]

Ah, I misread this as we didn't want the out symlink, sorry!

[catamorphism]

Low, not 1.0

[alexcrichton]

I think that this is safe to close. Now that everything is moved under $target, I don't think it's very necessary to create an out symlink (no one has requested it in a very long time).