Build a CommandPrototype instead of a ProcessBuilder

[tomaka]

With this change, the various commands in Cargo now build a CommandPrototype instead of a ProcessBuilder. This CommandPrototype is then passed to an object that implements the CommandsExecution trait, which executes them.

Ideally CommandPrototype would look like this:

enum CommandPrototype {
    Rustc {
        libraries: Vec<String>,
        opt_level: uint,
        input: Path,
        ... etc... (all the options that can be passed to rustc)
    },
    Rustdoc {
        ...  (all the options that can be passed to rustdoc)
    },
    Custom {
        cmd: ...,
        env: ...,
    }
}

...but that's a bit too much work for now (maybe in a follow-up).

What this enables is using the Cargo library to intercept the build commands and tweak them. I'm planning to write cargo-emscripten thanks to this change.

With this, one could also imagine embedding rustc and rustdoc directly inside cargo, if that is needed.

[alexcrichton]

This already has an unfortunately large number of arguments, perhaps the execution could be set after a Context is created?

[alexcrichton]

It may be worth having this trait inherit from Send + Sync to cut down on writing Send + Sync all over the place.

[tomaka]

Everything should be done except that problem with compilation options.

The lazy part inside me suggests that we just file an issue for this, and fix it when the issues in rustc are fixed. The ExecEngine is just an obscure feature that nobody will use in at least the next few weeks anyway.

The alternative is to add a template parameter to CompilationOptions, but that would need to be propagated everywhere.

[alexcrichton]

That all sounds good to me, thanks again for this! I'm excited to see what comes next :)

[alexcrichton]

@bors: r+ 3656bec

[bors]

⌛ Testing commit 3656bec with merge fc2e15e...

[bors]

☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-32, cargo-win-64