Want to contribute to ccache? Awesome!
There are several options:
- Ask a question in the issue tracker.
- Post your question to the mailing list.
- Chat in the Gitter room.
Please include at least the following information in your bug report:
- Which version of ccache you use.
- Which compiler you use, if applicable.
- Which operating system you use, if applicable.
- The problematic behavior you experienced (actual behavior).
- How you would like ccache to behave instead (expected behavior).
- Steps to reproduce the problematic behavior.
Also, consider reading Effective Ways to Get Help from Maintainers.
The preferred way is to create one or several pull request with your proposal(s) on GitHub.
Here are some hints to make the process smoother:
- If you plan to implement major changes it is wise to open an issue on GitHub (or ask in the Gitter room, or send a mail to the mailing list) asking for comments on your plans before doing the bulk of the work. That way you can avoid potentially wasting time on doing something that may need major rework to be accepted, or maybe doesn't end up being accepted at all.
- Is your pull request "work in progress", i.e. you don't think that it's ready for merging yet but you want early comments and CI test results? Then create a draft pull request as described in this Github blog post.
- If you have clang-format 6.0
or newer, you can run
make format
to adapt your modifications to ccache's code style. - Consider A Note About Git Commit Messages when writing commit messages.
ccache was written in C99 until 2019 when it started being converted to C++11. The conversion is a slow work in progress, which is why there is a lot of C-style code left. Please refrain from doing large C to C++ conversions; do it little by little.
Source code formatting is defined by .clang-format
in the root directory.
It's based on LLVM's code formatting
style with some deviations. You
can install the clang-format
6.0 or newer and run make format
to fix up the source code formatting.
Regarding naming:
- Use
UpperCamelCase
for types (e.g. classes and structs) and namespaces. - Use
UPPER_CASE
names for macros. - Use
snake_case
for other names (functions, variables, enum values, etc.). - Use an
m_
prefix for non-public member variables. - Use a
g_
prefix for global mutable variables. - Use a
k_
prefix for global constants.