Consider how to expose parallelism

[brson]

From @briansmith:

Note that gcc-rs has a way of doing parallel building, but we were not able to use it efficiently because we had other build steps that we also wanted to run in parallel, and gcc-rs's parallel build support doesn't compose well with additional build parallelism implemented in the build.rs. It would be good to factor parallel build support and dependency tracking out into a more general (not just asm/C/C++) library.

This seems like an important consideration (I didn't even realize there was an optional rayon feature). What should we do here?

At the least we could add a num_jobs knob so the user can deal with it themselves. This issue of coordinating build system parallelism though is quite cross-cutting. Whatever the ultimate solution here is seems like it will entail interaction between make, cargo, this crate, the cmake crate, etc.

Needs more design work before we take action.

[brson]

cc @sfackler @BurntSushi

[sfackler]

The new jobserver stuff in Cargo might help here right?

[alexcrichton]

Perhaps yeah, it'd want to integrate with that, but it wouldn't necessarily be an automatic interface to expose. Sort of what needs to be returned here is futures almost?