Crate evaluation for 2017-07-11: gcc

[brson]

Here's the etherpad from the review meeting. I intend to file bugs shortly:

Etherpad Mozilla

@kornel

Probably. At least it should add the Intel compiler.

re ToolFamily, this is actually a private type, so opening it doesn't matter.

@kornel

I've ran into a limitation of this crate - it's not possible to check what features (flags) compiler supports, e.g. OpenMP, or specific rare optimization flags -falign-stack=maintain-16-byte.

@kornel do you mind filing a bug on this? Hopefully it's something that could be added backwards compatibly.

Offhand, I don't know how you would check a compiler for supported flags. Maybe you can mention on the bug how this might be done.

@gnzlbg

How do you open an enum?

@gnzlbg by convention you add a #[doc(hidden)] __Nonexhaustive variant.

@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.

Awesome feedback @briansmith. I'll make sure to include this subject in the tracking issue. Coordinating parallelism across the build is kind of a hot topic these days, with cargo implementing (and presently reverting) make job server support. (Also my windows machine gets utterly DOSed every time I run cargo without -j1 ).

@briansmith

On Windows, we target -msvc but IIRC we didn't need to use the stuff in gcc-rs's windows_registry module at all. Maybe nowadays Cargo and rustc and gcc-rs do things automatically enough where that module isn't needed by dependent crates' bulid scripts and longer.

Yeah, this module doesn't belong. Plan is to pull it out into a different crate.