Figure out what we're going to do instead of rpath on windows

[brson]

When we install rust on windows the files are arranged in such a way that rustc can't be run because the dll's aren't found. We need to either adjust the directory structure specifically for windows, make some sort of 'rust shell' batch file that sets up the environment and runs cmd.exe, extend the system path to the appropriate directory, something.

[graydon]

The "standard" thing to do on win32 is to put all the .dll files a particular .exe depends on in the same directory as the .exe. That directory is automatically searched when resolving .dlls.

We can do this in the makefile by a post-build step that moves from $host/lib to $host/bin, or else in the nsis installer logic. Doesn't really matter, but my feeling is the former is a bit better since it means we can stop twiddling $PATH altogether on the windows command lines. Easier for devs to invoke rustc in their working directory.

[jckarter]

Could you use SetDllDirectory?

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx

[brson]

The makefile should be suitably abstracted at this point that we can just build with a completely different directory structure on windows.

But putting rustc's dependencies together only solves part of the problem, in that any other rustc-generated binaries still won't find their dependencies, possibly including our own tests.

[brson]

It looks like SetDllDirectory plus delay loading might actually be able to simulate rpath.

[brson]

AFAICT the mingw toolchain doesn't support delay loading - it is a feature of the visual studio linker.

[brson]

I'm going to look into putting the libs and bins into the same directory, and adding it to the system path.

[brson]

9e40e43 builds the libraries in the bin directory on win32

[brson]

OK, I've accomplished what I said I would. The windows experience still isn't very satisfying, but I'm considering this done.