Start using subtrees for external dependencies

[alexcrichton]

This commit removes the in-tree copies of lib{term,rustc_serialize,getopts} in favor of the upstream versions in the rust-lang github organization. The purpose of this is to both reduce duplication of code as well as enabling easier addition of external dependencies into the build of the compiler itself. There are a few points of note here:

• All external crates have been moved into a new src/external folder. This folder has a README explaining the git subtree setup as well as how to add new crates and update existing ones.
• External crates are still compiled as unstable (e.g. not accessible from stable code) via the #![staged_api] attribute guarded by the rust_build cfg.
• The API of getopts changed quite radically from the in-tree version, and all consumers were updated accordingly
• The name serialize has been purged as all crates now just explicitly link to rustc_serialize.

cc the initial discussion thread about this topic.

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @brson

cc @rust-lang/libs

[brson]

I want to think about this pretty hard if we're going to adopt sub_trees_ in addition to our sub_modules_. We've already got a lot of experience with submodules. Adding yet another thing for maintainers to understand is a big step.

[retep998]

The term that you are bringing in depends on winapi on Windows. I don't see a subtree for winapi though. I was just wondering how you intend to resolve that.

[ahmedcharles]

I agree with @brson about using both submodules and subtrees, even if development isn't supposed to happen in the rust tree itself.

[alexcrichton]

@brson, do you have some specific concerns you're worried about? From what I understand, the benefits are:

• It doesn't matter if the remote repositories change locations or go away.
• No extra management is necessary on those just building Rust. You only need to touch the subtree if you're updating it or adding a new one.
• No extra step is needed to check out the subtree

The downsides being

• The subtree can be modified to be different than the upstream copy.
• It looks like the subtree can be modified without worrying about the upstream copy.

I feel that the benefit of not having to worry about the remote repository going away far outweighs the downsides, personally.

---

@retep998

I forgot about that.

[bors]

☔ The latest upstream changes (presumably #26077) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Hm ok, we don't have a great way to deal with platform-specific dependencies right now as part of the build system, so moving to an out-of-tree term will likely not happen just yet. I'm also losing a bit of steam for this change as the future prospects don't seem super great, so for now I'm going to close this.