You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

130 lines
5.5 KiB

3 months ago
  1. # How to become a contributor and submit your own code
  2. ## Contributor License Agreements
  3. We'd love to accept your patches! Before we can take them, we have to jump a
  4. couple of legal hurdles.
  5. Please fill out either the individual or corporate Contributor License Agreement
  6. (CLA).
  7. * If you are an individual writing original source code and you're sure you
  8. own the intellectual property, then you'll need to sign an
  9. [individual CLA](https://developers.google.com/open-source/cla/individual).
  10. * If you work for a company that wants to allow you to contribute your work,
  11. then you'll need to sign a
  12. [corporate CLA](https://developers.google.com/open-source/cla/corporate).
  13. Follow either of the two links above to access the appropriate CLA and
  14. instructions for how to sign and return it. Once we receive it, we'll be able to
  15. accept your pull requests.
  16. ## Are you a Googler?
  17. If you are a Googler, please make an attempt to submit an internal change rather
  18. than a GitHub Pull Request. If you are not able to submit an internal change a
  19. PR is acceptable as an alternative.
  20. ## Contributing A Patch
  21. 1. Submit an issue describing your proposed change to the
  22. [issue tracker](https://github.com/google/googletest/issues).
  23. 2. Please don't mix more than one logical change per submittal, because it
  24. makes the history hard to follow. If you want to make a change that doesn't
  25. have a corresponding issue in the issue tracker, please create one.
  26. 3. Also, coordinate with team members that are listed on the issue in question.
  27. This ensures that work isn't being duplicated and communicating your plan
  28. early also generally leads to better patches.
  29. 4. If your proposed change is accepted, and you haven't already done so, sign a
  30. Contributor License Agreement (see details above).
  31. 5. Fork the desired repo, develop and test your code changes.
  32. 6. Ensure that your code adheres to the existing style in the sample to which
  33. you are contributing.
  34. 7. Ensure that your code has an appropriate set of unit tests which all pass.
  35. 8. Submit a pull request.
  36. ## The Google Test and Google Mock Communities
  37. The Google Test community exists primarily through the
  38. [discussion group](http://groups.google.com/group/googletestframework) and the
  39. GitHub repository. Likewise, the Google Mock community exists primarily through
  40. their own [discussion group](http://groups.google.com/group/googlemock). You are
  41. definitely encouraged to contribute to the discussion and you can also help us
  42. to keep the effectiveness of the group high by following and promoting the
  43. guidelines listed here.
  44. ### Please Be Friendly
  45. Showing courtesy and respect to others is a vital part of the Google culture,
  46. and we strongly encourage everyone participating in Google Test development to
  47. join us in accepting nothing less. Of course, being courteous is not the same as
  48. failing to constructively disagree with each other, but it does mean that we
  49. should be respectful of each other when enumerating the 42 technical reasons
  50. that a particular proposal may not be the best choice. There's never a reason to
  51. be antagonistic or dismissive toward anyone who is sincerely trying to
  52. contribute to a discussion.
  53. Sure, C++ testing is serious business and all that, but it's also a lot of fun.
  54. Let's keep it that way. Let's strive to be one of the friendliest communities in
  55. all of open source.
  56. As always, discuss Google Test in the official GoogleTest discussion group. You
  57. don't have to actually submit code in order to sign up. Your participation
  58. itself is a valuable contribution.
  59. ## Style
  60. To keep the source consistent, readable, diffable and easy to merge, we use a
  61. fairly rigid coding style, as defined by the
  62. [google-styleguide](https://github.com/google/styleguide) project. All patches
  63. will be expected to conform to the style outlined
  64. [here](https://google.github.io/styleguide/cppguide.html). Use
  65. [.clang-format](https://github.com/google/googletest/blob/master/.clang-format)
  66. to check your formatting.
  67. ## Requirements for Contributors
  68. If you plan to contribute a patch, you need to build Google Test, Google Mock,
  69. and their own tests from a git checkout, which has further requirements:
  70. * [Python](https://www.python.org/) v2.3 or newer (for running some of the
  71. tests and re-generating certain source files from templates)
  72. * [CMake](https://cmake.org/) v2.8.12 or newer
  73. ## Developing Google Test and Google Mock
  74. This section discusses how to make your own changes to the Google Test project.
  75. ### Testing Google Test and Google Mock Themselves
  76. To make sure your changes work as intended and don't break existing
  77. functionality, you'll want to compile and run Google Test and GoogleMock's own
  78. tests. For that you can use CMake:
  79. mkdir mybuild
  80. cd mybuild
  81. cmake -Dgtest_build_tests=ON -Dgmock_build_tests=ON ${GTEST_REPO_DIR}
  82. To choose between building only Google Test or Google Mock, you may modify your
  83. cmake command to be one of each
  84. cmake -Dgtest_build_tests=ON ${GTEST_DIR} # sets up Google Test tests
  85. cmake -Dgmock_build_tests=ON ${GMOCK_DIR} # sets up Google Mock tests
  86. Make sure you have Python installed, as some of Google Test's tests are written
  87. in Python. If the cmake command complains about not being able to find Python
  88. (`Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)`), try telling it
  89. explicitly where your Python executable can be found:
  90. cmake -DPYTHON_EXECUTABLE=path/to/python ...
  91. Next, you can build Google Test and / or Google Mock and all desired tests. On
  92. \*nix, this is usually done by
  93. make
  94. To run the tests, do
  95. make test
  96. All tests should pass.