From f46bd00e369ea9948e485ae8f65bef658637dc61 Mon Sep 17 00:00:00 2001 From: Sam Lunt Date: Mon, 27 Nov 2017 17:07:56 -0600 Subject: make includes system --- googlemock/CMakeLists.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'googlemock') diff --git a/googlemock/CMakeLists.txt b/googlemock/CMakeLists.txt index 724fdd5f..a4e98afb 100644 --- a/googlemock/CMakeLists.txt +++ b/googlemock/CMakeLists.txt @@ -101,8 +101,8 @@ cxx_library(gmock_main # to the targets for when we are part of a parent build (ie being pulled # in via add_subdirectory() rather than being a standalone build). if (DEFINED CMAKE_VERSION AND NOT "${CMAKE_VERSION}" VERSION_LESS "2.8.11") - target_include_directories(gmock INTERFACE "${gmock_SOURCE_DIR}/include") - target_include_directories(gmock_main INTERFACE "${gmock_SOURCE_DIR}/include") + target_include_directories(gmock SYSTEM INTERFACE "${gmock_SOURCE_DIR}/include") + target_include_directories(gmock_main SYSTEM INTERFACE "${gmock_SOURCE_DIR}/include") endif() ######################################################################## -- cgit v1.2.3 From cf3adad594b68caad7a4093dbcd29c6bd7693eb0 Mon Sep 17 00:00:00 2001 From: Carlos O'Ryan Date: Sun, 3 Dec 2017 14:24:13 -0500 Subject: Add licenses() directive for googlemock/tests. Without the directive embedding googletest into third_party breaks any //... target. --- googlemock/test/BUILD.bazel | 2 ++ 1 file changed, 2 insertions(+) (limited to 'googlemock') diff --git a/googlemock/test/BUILD.bazel b/googlemock/test/BUILD.bazel index 6e67f187..9f1a64d8 100644 --- a/googlemock/test/BUILD.bazel +++ b/googlemock/test/BUILD.bazel @@ -32,6 +32,8 @@ # # Bazel Build for Google C++ Testing Framework(Google Test)-googlemock +licenses(["notice"]) + """ gmock own tests """ cc_test( -- cgit v1.2.3 From 23a014ab578682ae11c3e68c77a1cde3b77f7a90 Mon Sep 17 00:00:00 2001 From: Carlos O'Ryan Date: Mon, 11 Dec 2017 19:33:27 -0500 Subject: Refactor docs about contributions to CONTRIBUTING.md. Per the review comments. --- googlemock/README.md | 32 ---------- googlemock/docs/DevGuide.md | 132 --------------------------------------- googlemock/docs/Documentation.md | 2 +- 3 files changed, 1 insertion(+), 165 deletions(-) delete mode 100644 googlemock/docs/DevGuide.md (limited to 'googlemock') diff --git a/googlemock/README.md b/googlemock/README.md index f941f158..1170cfab 100644 --- a/googlemock/README.md +++ b/googlemock/README.md @@ -337,38 +337,6 @@ use the new matcher API ( [polymorphic](./docs/CookBook.md#writing-new-polymorphic-matchers)). Matchers defined using `MATCHER()` or `MATCHER_P*()` aren't affected. -### Developing Google Mock ### - -This section discusses how to make your own changes to Google Mock. - -#### Testing Google Mock Itself #### - -To make sure your changes work as intended and don't break existing -functionality, you'll want to compile and run Google Test's own tests. -For that you'll need Autotools. First, make sure you have followed -the instructions above to configure Google Mock. -Then, create a build output directory and enter it. Next, - - ${GMOCK_DIR}/configure # try --help for more info - -Once you have successfully configured Google Mock, the build steps are -standard for GNU-style OSS packages. - - make # Standard makefile following GNU conventions - make check # Builds and runs all tests - all should pass. - -Note that when building your project against Google Mock, you are building -against Google Test as well. There is no need to configure Google Test -separately. - -#### Contributing a Patch #### - -We welcome patches. -Please read the [Developer's Guide](docs/DevGuide.md) -for how you can contribute. In particular, make sure you have signed -the Contributor License Agreement, or we won't be able to accept the -patch. - Happy testing! [gtest_readme]: ../googletest/README.md "googletest" diff --git a/googlemock/docs/DevGuide.md b/googlemock/docs/DevGuide.md deleted file mode 100644 index cae07e70..00000000 --- a/googlemock/docs/DevGuide.md +++ /dev/null @@ -1,132 +0,0 @@ - - -If you are interested in understanding the internals of Google Mock, -building from source, or contributing ideas or modifications to the -project, then this document is for you. - -# Introduction # - -First, let's give you some background of the project. - -## Licensing ## - -All Google Mock source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php). - -## The Google Mock Community ## - -The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the -[issue tracker](https://github.com/google/googletest/issues) and, to a lesser extent, the [source control repository](../). You are definitely encouraged to contribute to the -discussion and you can also help us to keep the effectiveness of the -group high by following and promoting the guidelines listed here. - -### Please Be Friendly ### - -Showing courtesy and respect to others is a vital part of the Google -culture, and we strongly encourage everyone participating in Google -Mock development to join us in accepting nothing less. Of course, -being courteous is not the same as failing to constructively disagree -with each other, but it does mean that we should be respectful of each -other when enumerating the 42 technical reasons that a particular -proposal may not be the best choice. There's never a reason to be -antagonistic or dismissive toward anyone who is sincerely trying to -contribute to a discussion. - -Sure, C++ testing is serious business and all that, but it's also -a lot of fun. Let's keep it that way. Let's strive to be one of the -friendliest communities in all of open source. - -### Where to Discuss Google Mock ### - -As always, discuss Google Mock in the official [Google C++ Mocking Framework discussion group](http://groups.google.com/group/googlemock). You don't have to actually submit -code in order to sign up. Your participation itself is a valuable -contribution. - -# Working with the Code # - -If you want to get your hands dirty with the code inside Google Mock, -this is the section for you. - -## Checking Out the Source from Subversion ## - -Checking out the Google Mock source is most useful if you plan to -tweak it yourself. You check out the source for Google Mock using a -[Subversion](http://subversion.tigris.org/) client as you would for any -other project hosted on Google Code. Please see the instruction on -the [source code access page](../) for how to do it. - -## Compiling from Source ## - -Once you check out the code, you can find instructions on how to -compile it in the [README](../README.md) file. - -## Testing ## - -A mocking framework is of no good if itself is not thoroughly tested. -Tests should be written for any new code, and changes should be -verified to not break existing tests before they are submitted for -review. To perform the tests, follow the instructions in [README](../README.md) and -verify that there are no failures. - -# Contributing Code # - -We are excited that Google Mock is now open source, and hope to get -great patches from the community. Before you fire up your favorite IDE -and begin hammering away at that new feature, though, please take the -time to read this section and understand the process. While it seems -rigorous, we want to keep a high standard of quality in the code -base. - -## Contributor License Agreements ## - -You must sign a Contributor License Agreement (CLA) before we can -accept any code. The CLA protects you and us. - - * 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](http://code.google.com/legal/individual-cla-v1.0.html). - * If you work for a company that wants to allow you to contribute your work to Google Mock, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html). - -Follow either of the two links above to access the appropriate CLA and -instructions for how to sign and return it. - -## Coding Style ## - -To keep the source consistent, readable, diffable and easy to merge, -we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project. All patches will be expected -to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html). - -## Submitting Patches ## - -Please do submit code. Here's what you need to do: - - 1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only. - 1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Mock issue tracker](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one. - 1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches. - 1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md). - 1. Ensure that there are unit tests for your code. - 1. Sign a Contributor License Agreement. - 1. Create a patch file using `svn diff`. - 1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews. You can read about the tool [here](https://github.com/rietveld-codereview/rietveld/wiki). When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it. There are several ways to upload the patch. We recommend using the [upload\_gmock.py](../scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk. - -## Google Mock Committers ## - -The current members of the Google Mock engineering team are the only -committers at present. In the great tradition of eating one's own -dogfood, we will be requiring each new Google Mock engineering team -member to earn the right to become a committer by following the -procedures in this document, writing consistently great code, and -demonstrating repeatedly that he or she truly gets the zen of Google -Mock. - -# Release Process # - -We follow the typical release process for Subversion-based projects: - - 1. A release branch named `release-X.Y` is created. - 1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable. - 1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch. - 1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time). - 1. Go back to step 1 to create another release branch and so on. - - ---- - -This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project. Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/). diff --git a/googlemock/docs/Documentation.md b/googlemock/docs/Documentation.md index a0311871..16083e70 100644 --- a/googlemock/docs/Documentation.md +++ b/googlemock/docs/Documentation.md @@ -11,5 +11,5 @@ the respective git branch/tag).** To contribute code to Google Mock, read: - * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch. + * [CONTRIBUTING](../CONTRIBUTING.md) -- read this _before_ writing your first patch. * [Pump Manual](../../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files. -- cgit v1.2.3