Contributing to ccache
Want to contribute to ccache? Awesome!
Asking a question?
There are several options:
Reporting an issue?
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:
- Have a look in
ARCHITECTURE.mdfor an overview of the source code tree.
- 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.
- Please add test cases for your new changes if applicable.
- Please follow the ccache's code style (see the section below).
- Consider A Note About Git Commit Messages when writing commit messages.
Source code formatting is defined by
.clang-format in the root directory. The
format is loosely based on LLVM's code formatting
style with some exceptions. Run
make format (or
ninja format if you use Ninja) to format changes according
to ccache's code style. Or even better: set up your editor to run
<ccache-top-dir>/misc/clang-format (or any other Clang-Format version 10
binary) automatically when saving. Newer Clang-Format versions likely also work
Please follow these conventions:
UpperCamelCasefor types (e.g. classes and structs).
UPPER_CASEnames for macros and (non-class) enum values.
snake_casefor other names (namespaces, functions, variables, enum class values, etc.). (Namespaces used to be in
UpperCamelCase; transition is work in progress.)
- Use an
m_prefix for non-public member variables.
- Use a
g_prefix for global mutable variables.
- Use a
k_prefix for global constants.
- Always use curly braces around if/for/while/do bodies, even if they only contain one statement.