# Crate evaluation for 2017-07-11: gcc **URL:** \ **Category:** libs\ **Created:** [June 27, 2017, 1:00pm UTC](https://internals.rust-lang.org/t/crate-evaluation-for-2017-07-11-gcc/5450 "2017-06-27T13:00:01Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![burntsushi](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/burntsushi/32/279_2.png) [@burntsushi](https://internals.rust-lang.org/u/burntsushi)\ **Post date:** [June 27, 2017, 1:00pm UTC](https://internals.rust-lang.org/t/crate-evaluation-for-2017-07-11-gcc/5450/1 "2017-06-27T13:00:01Z")
# Crate evaluation for 2017-07-11: gcc For additional contribution opportunities, see the [main libz blitz thread](https://internals.rust-lang.org/t/rust-libs-blitz/5184). **This post is a wiki. Feel free to edit it.** ## Links - [https://crates.io/crates/gcc](https://crates.io/crates/gcc) - [https://github.com/alexcrichton/gcc-rs](https://github.com/alexcrichton/gcc-rs) - [https://docs.rs/gcc/](https://docs.rs/gcc/) # Needs your help! Anything that is not checked off still needs your help! There is no need to sign up or ask for permission - follow any of these links and leave your thoughts: ## Guidelines checklist **Legend** - `[y]` = guideline is adhered to, no work needed. - `[n]` = guideline may need work, see comments nearby - `[/]` = guideline not applicable to this crate **Checklist** [Guidelines checklist](https://public.etherpad-mozilla.org/p/rust-api-guidelines-gcc) This document is collaboratively editable. Pick a few of the guidelines, compare the `gcc` crate against them, and fill in the checklist with `[y]` if the crate conforms to the guideline, `[n]` if the crate does not conform, and `[/]` if the guideline does not apply to this crate. Each guideline is explained in more detail [here](https://github.com/brson/rust-api-guidelines). If `[n]`, please add a brief note on the following line with an explanation. For example: ```nohighlight - [n] Crate name is a palindrome (C-PALINDROME) - gcc backwards is ccg which is not the same as gcc ``` ## API guideline updates What lessons can we learn from `gcc` that will be broadly applicable to other crates? Please leave a comment in that issue with your ideas! ## Discussion topics Should we rename this crate? This crate includes some [VS discovery code](https://github.com/alexcrichton/gcc-rs/blob/master/src/windows_registry.rs) that seems a bit out of place. Do most build scripts that use C compilers need this module? Can it be moved into another crate? [ToolFamily is a closed enum](https://docs.rs/gcc/0.3.51/src/gcc/lib.rs.html#120). Should it be opened? `Tool` claims to be represent a C compiler, but at least windows\_registry will return Tool’s for things that are not compilers. What needs to be clarified here? Can `.o` files be generated by this crate? This seems to want to produce static libraries only. `expand` seems weird. What’s it doing? What does it mean to convert multiple input files to a Vec? It’s pretty clear this library has evolved to accommodate practical matters as they arise - it does not appear to be a comprehensive C compiler driver. Should we try to featurefy it for 1.0? Is the scope of this crate (disregarding windows\_registry) simple driving C / C++ compilers to produce static libraries? What about dynamic libraries, what about object files, what about driving the linker directly? One could imagine e.g. extracting rustc’s entire backend linker abstraction so that others could use it - would that go here, another crate? Inconsistency - compile\_library() shorthand supports setting multiple files from a slice, but the “full” usage via Config does not (it requires multiple calls to .file()). There’s cpp(bool), but it doesn’t specify the C++ version. Similarly there’s no way to specify C version (some compilers default to C99, some require opt-in, so an unspecified version is non-portable). - budziq: An enum or even a separate builder for compiler configuration/variants might be more appropriate here This crate panics on errors, as do many build-time crates. What do we think of this? ## Crate issues - Explain what library names are valid for `compile_input` - Is it just `.a`? `.so`, etc.? - Clarify doc language around ‘gcc’, ‘C compiler’, ‘tool’ etc. - These are all used fairly imprecisely - `cargo_metadata` - explain more precisely what this metadata is and where it is emitted # How are we tracking? > **** > > ## Pre-review checklist > > Do these before the libs team review. > > - [x] Create evaluation thread based on [this template](https://public.etherpad-mozilla.org/p/rust-libz-blitz-eval-template) > - [] Work with author and issue tracker to identify known blockers > - [] Compare crate to guidelines by filling in checklist > - [] Record other questions and notes about crate > - [] Draft several use case statements to serve as cookbook examples > - [] Record recommendations for updated guidelines > > ## Post-review checklist > > Do these after the libs team review. > > - [] Publish libs team meeting video > - [] Create new issues and tracking issue on crate’s issue tracker > - [] Solicit use cases for cookbook examples related to the crate > - [] File issues to implement cookbook examples > - [] File issues to update guidelines > - [] Post all approachable issues to TWiR call for participation thread > - [] Update links in coordination thread --- _[View the full topic](https://internals.rust-lang.org/t/crate-evaluation-for-2017-07-11-gcc/5450)._