Add build instructions to contributing.md

This commit is contained in:
Lotte Steenbrink 2019-01-04 15:39:22 +01:00 committed by Martin Hořeňovský
parent c1720d0c42
commit bc02ada4b0

View File

@ -1,8 +1,8 @@
<a id="top"></a>
# Contributing to Catch
So you want to contribute something to Catch? That's great! Whether it's a bug fix, a new feature, support for
additional compilers - or just a fix to the documentation - all contributions are very welcome and very much appreciated.
So you want to contribute something to Catch? That's great! Whether it's a bug fix, a new feature, support for
additional compilers - or just a fix to the documentation - all contributions are very welcome and very much appreciated.
Of course so are bug reports and other comments and questions.
If you are contributing to the code base there are a few simple guidelines to keep in mind. This also includes notes to
@ -16,7 +16,7 @@ Ongoing development is currently on _master_. At some point an integration branc
## Directory structure
_Users_ of Catch primarily use the single header version. _Maintainers_ should work with the full source (which is still,
_Users_ of Catch primarily use the single header version. _Maintainers_ should work with the full source (which is still,
primarily, in headers). This can be found in the `include` folder. There are a set of test files, currently under
`projects/SelfTest`. The test app can be built via CMake from the `CMakeLists.txt` file in the root, or you can generate
project files for Visual Studio, XCode, and others (instructions in the `projects` folder). If you have access to CLion,
@ -37,20 +37,41 @@ as these are managed by the scripts!__
## Testing your changes
Obviously all changes to Catch's code should be tested. If you added new functionality, you should add tests covering and
showcasing it. Even if you have only made changes to Catch internals (ie you implemented some performance improvements),
you should still test your changes.
Obviously all changes to Catch's code should be tested. If you added new
functionality, you should add tests covering and showcasing it. Even if you have
only made changes to Catch internals (i.e. you implemented some performance
improvements), you should still test your changes.
This means 3 things
* Compiling Catch's SelfTest project -- code that does not compile is evidently incorrect. Obviously, you are not expected to
have access to all compilers and platforms Catch supports, Catch's CI pipeline will compile your code using supported compilers
once you open a PR.
* Running the SelfTest binary. There should be no unexpected failures on simple run.
* Running Catch's approval tests. Approval tests compare current output of the SelfTest binary in various configurations against
known good output. Catch's repository provides utility scripts `approvalTests.py` to help you with this. It needs to be passed
the SelfTest binary compiled with your changes, like so: `$ ./scripts/approvalTests.py clang-build/SelfTest`. The output should
be fairly self-explanatory.
* Compiling Catch's SelfTest project:
```
$ cd Catch2
$ cmake -Bcmake-build-debug -H. -DCATCH_BUILD_TESTING=ON
$ cd cmake-build-debug/
$ make
```
-- code that does not compile is evidently incorrect. Obviously, you are not
expected to have access to all compilers and platforms Catch supports, Catch's
CI pipeline will compile your code using supported compilers once you open a PR.
* Running the SelfTest binary:
```
$ ./cmake-build-debug/projects/SelfTest
```
There should be no unexpected failures on simple run.
*Note: on Windows, the binary is located at `cmake-build-debug\projects\Debug\SelfTest`*
* Running Catch's approval tests:
```
$ ./scripts/approvalTests.py
```
Approval tests compare current output of the SelfTest binary in various
configurations against known good output. If you've configured the SelfTest
binary with your changes to be located in any other directory than
`/cmake-build-debug/projects/SelfTest`, its path needs to be passed to the
script, like so: `$ ./scripts/approvalTests.py clang-build/SelfTest`.
The output should be fairly self-explanatory.