I agree, given that this is a wrapper for whatever the platform C compiler happens to be (generally gcc, clang, or MSVC), the name gcc is very misleading.
The cc crate is a cycle collector from pre-1.0, has no dependent crates, doesn't compile on Rust 1.0 or later, and hasn't been updated since 2014 (there's one commit in GitHub from 2015 to fix one 1.0 compat issue, but there are others that are not fixed). It's possible that we could just ask @cmr if we could take over the name.
Other alternate obvious names could be compilec or ccompiler (or snake or kebab case versions, like compile-c, compile_c, c-compiler, or c_compiler) but those are a lot more cumbersome. cc would be my preference, followed by compilec, followed by just sticking with gcc and accepting the confusion that causes.
This link goes to an API design guidelines issue for error-chain. Not sure if that issue should be made generic, or should file a new one for gcc and link to that.
This crate’s interesting as a layer of gloss over other tools. My first impression was that it should make more effort to return errors rather than panicking. But maybe it’s a bit special for being a tool you use in a build.rs, where panicking is how you bork the build.
I don’t really use build scripts or write C / C++ though, so am interested in what kinds of things people are putting in them.
I didn’t see a cookbook issue for this so I made one: https://github.com/brson/rust-cookbook/issues/236. It’s a weird one since it’s a build-time crate, but it would be good to figure out how to teach people about it.
I just removed the link and updated the template to not include the link. Pre-opening guidelines issues hasn’t been that useful. When they come up we can note them in here and in the op and file them later.
Sure. Had been asking about that since I was wondering if we should add a guideline on crate naming to the guidelines. For instance, a few people have noted that “gcc” is a confusing name for a crate that’s used to invoke MSVC, clang, gcc, or other C compilers depending on the target. Might be worth adding a guideline for checking the crate name to make sure that it’s reasonably discoverable and descriptive of what the crate is about.
Thanks to those that filled out the checklist! Big, big help. If you have time you might translate the obvious ones to issue titles in the op under the ‘crate issues’ section.
This one is going to the libs team tomorrow. It went by too quick… but fortunately it’s a small crate.
This one is an interesting crate, because it is a very practical crate - it’s obviously evolved organically to accommodate whatever needed to be done in the real world. And it also seems to me like there’s quite a lot one might want to do with a C compiler that this doesn’t let you do. This seems firmly oriented at compiling a set of individual C/C++ files into static libraries so they can be statically linked to Rust crates; with more complex build tasks relegated to other crates like cmake / pkg-config. The exception being the weirdo windows_registry module which I think is currently the best way to do any VS stuff one might want.
I wonder how much we want to try to add features to the design and/or clean up the existing design.
It looks to me like it would make sense to punt the VS code to yet another crate, and have this one depend on it just so it can implement Config / Tool for MSVC.
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.
ring’s build.rs at https://github.com/briansmith/ring/blob/master/build.rs is probably one of the more advanced users of this crate. In particular, note that we compile asm code and C code and if you look at the history of the file we compiled C++ code too. We also extensively customized the compilation and linking with additional options, in order to achieve parity with the Makefile-based system that the usage of gcc-rs replaced. We also spent considerable effort getting cross-compilation to various targets—especially ARM/Aarch64 and ARM/Aarch64 Android & iOS—to work.
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.
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.
re ToolFamily, this is actually a private type, so opening it doesn’t matter.
@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 by convention you add a #[doc(hidden)] __Nonexhaustive variant.
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 ).
Yeah, this module doesn’t belong. Plan is to pull it out into a different crate.
).