Crate evaluation for 2017-07-11: gcc
For additional contribution opportunities, see the main libz blitz thread.
This post is a wiki. Feel free to edit it.
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:
[y] = guideline is adhered to, no work needed.
[n] = guideline may need work, see comments nearby
[/] = guideline not applicable to this crate
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. If
[n], please add a brief note on the following line with an explanation. For example:
- [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!
Should we rename this crate?
This crate includes some VS discovery code 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. 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?
.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?
- Explain what library names are valid for
- Is it just
- 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?
Do these before the libs team review.
- [x] Create evaluation thread based on this 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
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