mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +01:00
0f55045526
This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any project could use it for benchmark generation. A dummy benchmark is added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of the build process. The current version does not utilize LLVM LNT and LLVM CMake infrastructure, but that might be sufficient for most users. Two introduced CMake variables: * `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark targets * `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated benchmark targets to the list of default LLVM targets (i.e. if `ON` benchmarks will be built upon standard build invocation, e.g. `ninja` or `make` with no specific targets) List of modifications: * `BENCHMARK_ENABLE_TESTING` is disabled * `BENCHMARK_ENABLE_EXCEPTIONS` is disabled * `BENCHMARK_ENABLE_INSTALL` is disabled * `BENCHMARK_ENABLE_GTEST_TESTS` is disabled * `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled Original discussion can be found here: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html Reviewed by: dberris, lebedev.ri Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines, dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50894 llvm-svn: 340809
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
# How to contribute #
|
|
|
|
We'd love to accept your patches and contributions to this project. There are
|
|
a just a few small guidelines you need to follow.
|
|
|
|
|
|
## Contributor License Agreement ##
|
|
|
|
Contributions to any Google project must be accompanied by a Contributor
|
|
License Agreement. This is not a copyright **assignment**, it simply gives
|
|
Google permission to use and redistribute your contributions as part of the
|
|
project.
|
|
|
|
* If you are an individual writing original source code and you're sure you
|
|
own the intellectual property, then you'll need to sign an [individual
|
|
CLA][].
|
|
|
|
* If you work for a company that wants to allow you to contribute your work,
|
|
then you'll need to sign a [corporate CLA][].
|
|
|
|
You generally only need to submit a CLA once, so if you've already submitted
|
|
one (even if it was for a different project), you probably don't need to do it
|
|
again.
|
|
|
|
[individual CLA]: https://developers.google.com/open-source/cla/individual
|
|
[corporate CLA]: https://developers.google.com/open-source/cla/corporate
|
|
|
|
Once your CLA is submitted (or if you already submitted one for
|
|
another Google project), make a commit adding yourself to the
|
|
[AUTHORS][] and [CONTRIBUTORS][] files. This commit can be part
|
|
of your first [pull request][].
|
|
|
|
[AUTHORS]: AUTHORS
|
|
[CONTRIBUTORS]: CONTRIBUTORS
|
|
|
|
|
|
## Submitting a patch ##
|
|
|
|
1. It's generally best to start by opening a new issue describing the bug or
|
|
feature you're intending to fix. Even if you think it's relatively minor,
|
|
it's helpful to know what people are working on. Mention in the initial
|
|
issue that you are planning to work on that bug or feature so that it can
|
|
be assigned to you.
|
|
|
|
1. Follow the normal process of [forking][] the project, and setup a new
|
|
branch to work in. It's important that each group of changes be done in
|
|
separate branches in order to ensure that a pull request only includes the
|
|
commits related to that bug or feature.
|
|
|
|
1. Do your best to have [well-formed commit messages][] for each change.
|
|
This provides consistency throughout the project, and ensures that commit
|
|
messages are able to be formatted properly by various git tools.
|
|
|
|
1. Finally, push the commits to your fork and submit a [pull request][].
|
|
|
|
[forking]: https://help.github.com/articles/fork-a-repo
|
|
[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
|
[pull request]: https://help.github.com/articles/creating-a-pull-request
|