Contributions to this project are released under the project's open source license.
Please note that this project is released with a Contributor Code of Conduct. By participating in this porject you agree to abide eby its terms.
As noted in the README, this project requires Meson to build.
For a development setup, we recomend running meson build --buildtype=debug
rather than just meson build
.
We also recomend the use of the 'build' directory name as this works with the existing .gitignore rules
and keeps a nice commonailty between all developer setups.
These are intended to be run from inside your build directory
- Building the library component and tests:
ninja
(meson compile
) - Running tests:
ninja test
(meson test
), or to view the raw outputmeson test -v
- Debugging tests:
meson test --gdb
- Fork and clone the repository
- Create a new branch:
git switch -c branch-name
(git checkout -b branch-name
in the old syntax) - Make your change, create unit tests and sure all tests new and old pass
- Push to your fork and submit a pull request
Before your pull request will be accepted, please keep in mind that unless your change is a bugfix, writing unit tests to proove your new code is mandatory.
Additionally, please write good and descriptive commit messages that both summerise the change and, if necessary, expand on the summary using description lines. "Patched the utility header" is, while terse and correct, an example of a bad commit message. "Fixed a bug in substrate/utility causing issues in make_array<>() handling" is an example of a better commit message.
We would like to be able to look back through the commit history and tell what happened, when, and why without having
to dip into the commit descriptions as this improves the git bisect
experience and improves everyone's lives.
We use rebasing to merge pull requests, so please keep this in mind and aim to keep a linear history.