@ -17,7 +17,7 @@ We welcome any help, for example contributing lens data (images), code contribut
Code contributions can be performed via *pull requests* (PR) on GitHub (if you cannot or do not want to use GitHub, see [3. Contributing code via email](#3-contributing-code-via-email)).
Code contributions can be performed via *pull requests* (PR) on GitHub (if you cannot or do not want to use GitHub, see [3. Contributing code via email](#3-contributing-code-via-email)).
For this to work you first need to [create a user account on GitHub](https://help.github.com/articles/signing-up-for-a-new-github-account/) if you don't already have one.
For this to work you first need to [create a user account on GitHub](https://help.github.com/articles/signing-up-for-a-new-github-account/) if you don't already have one.
A pull request should preferable contain only one new feature or bug fix etc. Since it is not uncommon to work on several PRs at the same time
A pull request should preferable contain only one new feature, bug fix, etc. Since it is not uncommon to work on several PRs at the same time
it is recommended to create a new _branch_ for each PR. In this way PRs can easily be separated and the review and merge process becomes cleaner.
it is recommended to create a new _branch_ for each PR. In this way PRs can easily be separated and the review and merge process becomes cleaner.
As a rule-of-thumb:
As a rule-of-thumb:
@ -71,22 +71,27 @@ Once you have a GitHub login:
$ rm -rf build
$ rm -rf build
$ mkdir build && cd build
$ mkdir build && cd build
$ cmake -DCMAKE_BUILD_TYPE=Release ..
$ cmake -DCMAKE_BUILD_TYPE=Release ..
$ make
$ cmake --build . --parallel
6. Now, make your change(s), add tests for your changes, and commit each change:
6. Now, make your change(s), add tests for your changes, and commit each change:
...
...
$ git commit -m "Commit message 1"
$ git commit -m "Commit message 1"
...
...
$ git commit -m "Commit message 2"
$ git commit -m "Commit message 2"
Please keep in mind that the project has a Continuous Integration job to check that your new code is satisfying the
format defined in the file `.clang-format`. Use your preferred text editor, IDE or method to make sure your code is
properly formatted before creating the PR.
Note: You can use the script `contrib/scripts/clangFormatWholeProject.sh` to format the whole project.
7. Make sure the tests pass:
7. Make sure the tests pass:
$ make tests # Integration tests
$ ctest
$./bin/unit_tests # Unit tests
Exiv2's (new) test system is described in more detail in the [doc.md](tests/doc.md) and [writing_tests.md](tests/writing_tests.md) files, and a description of the old
Exiv2's (new) test system is described in more detail in the [doc.md](tests/doc.md) and [writing_tests.md](tests/writing_tests.md) files, and a description of the old
test system can be found in the Redmine wiki: [How do I run the test suite for Exiv2](http://dev.exiv2.org/projects/exiv2/wiki/How_do_I_run_the_test_suite_for_Exiv2)
test system can be found in the Redmine wiki: [How do I run the test suite for Exiv2](http://dev.exiv2.org/projects/exiv2/wiki/How_do_I_run_the_test_suite_for_Exiv2)