Important
Currently the contribution guidelines are a work in progress. Please check back later for more information.
First off, thanks for taking the time to contribute! ❤️
All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉
And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:
- Star the project
- Refer this project in your project's readme
- Mention the project at local meetups and tell your friends/colleagues
- I Have a Question
- I Want To Contribute
- Your First Code Contribution
- How to manually build CCMath with the command line
If you want to ask a question, we assume that you have read the available Documentation.
Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue. It is also advisable to search the internet for answers first.
If you then still feel the need to ask a question and need clarification, we recommend the following:
- Open an Issue.
- Provide as much context as you can about what you're running into.
- Provide project and platform versions (nodejs, npm, etc), depending on what seems relevant.
We will then take care of the issue as soon as possible.
When contributing to this project, you must agree that you have authored 100% of the content, that you have the necessary rights to the content and that the content you contribute may be provided under the project license.
Before any code can be written consider these core tenets of CCMath as you work on the project.
- At all times should code produced for CCMath be evaluable at compile time. (e.g.
constexpr
&static_assert
) - Always aim to have the same output as the standard. Never compromise on accuracy.
- Always aim to have speed's comparable to the standard. (Aim for being no slower than 1/2 the speed of the standard if possible)
- Always aim to have your code work with
static_assert
. - At all times should you prefer a generic solution over a platform dependent solution if possible.
- You should always mimic the behavior of every compiler we support. (This is most visible in
ccm::fpclassify
) - Always have a comprehensive test suite for your implementation that covers all edge cases.
- Ensure your code is always properly documented with doxygen in a detailed manner.
- Always have the same API layout as the standard. (This can be cross-referenced from cppreference)
WIP
- CMake 3.18+
- Git
- Ninja (for Linux & macOS
- Clang or GCC (for Linux & macOS)
- Visual Studio 22 (for Windows)
Step 1: Clone the repository
git clone https://github.com/Rinzii/ccmath.git
Step 2: (recommended) Check out the dev branch
git checkout dev
For Linux & macOS:
# Run commands in the project root directory
# Configure cmake to use default compiler
# Preset can alternatively be set to ninja-gcc or ninja-clang for use with gcc or clang
cmake -S . --preset=default -B build
# Build the project
# --config= can be set to Debug, Release, or RelWithDebInfo
cmake --build build --config=Debug
For Windows:
# Run commands in the project root directory
# Configure cmake to use Visual Studio
cmake -S . --preset=vs22 -B build
# Build the project
# --config= can be set to Debug, Release, or RelWithDebInfo
cmake --build build --config=Debug
# Run commands from the project root directory
# Must have built the project before running tests
cd build
ctest -C Debug