Reorganize project infrastructure

[ebkalderon]

There are some major changes coming to our core infrastructure. Currently, the overall Amethyst project consists of three repositories: amethyst, amethyst_cli, and amethyst_opengl.

Amethyst is set for future expansion, and the current approach to organizing our code is not maintainable. I propose the following:

• Consolidate all of the tools into an "amethyst_tools" repository. All future tools will reside only in this repository.
  • Move the "amethyst_cli" crate into this repository.

This might cause some breakage, but this must be minimized as much as possible. Let's use Piston's approach for managing multiple crates under one repository as prior art.

Progress has begun on the reorg branch.

This is the tools-side counterpart of Amethyst issue #13.

Edit: See the caveats below.

[ebkalderon]

Unfortunately, this doesn't seem to be going smoothly.

1. Cargo generates an unnecessary libamethyst_tools.rlib library when I compile.
2. I cannot find the binaries inside the target/ folder and launch them without installing them onto the host system.

[ebkalderon]

Unfortunately, this doesn't seem to be going smoothly.

1. Cargo generates an unnecessary libamethyst_tools.rlib library when I compile.
2. I cannot find the binaries inside the target/ folder and launch them without installing them onto the host system.

[ebkalderon]

Here are some possible alternatives for better hosting multiple optional binaries in a single repository:

1. Somehow allowing binary crate dependencies in a similar manner to library crates, which would be the ideal route, but is unlikely to ever happen in Cargo.
2. Conditional compilation of binaries using Cargo [features]. This doesn't exist, but there is rust-lang/cargo#2080 which links to rust-lang/cargo#1570. A pull request implementing this exists, but appears to have gone stale.

Neither idea is very appealing. Suggestions are welcome!

[ebkalderon]

Here are some possible alternatives for better hosting multiple optional binaries in a single repository:

1. Somehow allowing binary crate dependencies in a similar manner to library crates, which would be the ideal route, but is unlikely to ever happen in Cargo.
2. Conditional compilation of binaries using Cargo [features]. This doesn't exist, but there is rust-lang/cargo#2080 which links to rust-lang/cargo#1570. A pull request implementing this exists, but appears to have gone stale.

Neither idea is very appealing. Suggestions are welcome!

[ebkalderon]

Honestly, I think the best route for now is to make each binary a [[bin]] target and move on. Currently, there is only one tool (the amethyst CLI client), so we don't actually have to worry about dependencies and conditional compilation.

It's a hard decision, but to keep Amethyst moving, I'm going to mark this improvement as stalled. Discussion is still welcome, and resolving this ASAP is still a priority, but it shouldn't have to block the 0.2.0 release if we don't have any reason to do so yet.

[ebkalderon]

Honestly, I think the best route for now is to make each binary a [[bin]] target and move on. Currently, there is only one tool (the amethyst CLI client), so we don't actually have to worry about dependencies and conditional compilation.

It's a hard decision, but to keep Amethyst moving, I'm going to mark this improvement as stalled. Discussion is still welcome, and resolving this ASAP is still a priority, but it shouldn't have to block the 0.2.0 release if we don't have any reason to do so yet.