Add Bazel build rules.

This adds support for building effcee with Bazel (https://bazel.build).

It automatically pulls the googletest and re2 repositories when building
with Bazel.  I did not add a sha256 attribute to fix the version of the
external repos to get, so by default this tracks top-of-master for those
repos.

It's easy to fix the versions by adding the sha256 attribute that Bazel
suggests when it starts.

1 files changed, 25 insertions, 24 deletions

diff --git a/DEVELOPMENT.howto.md b/DEVELOPMENT.howto.md
index ce2afdd..6f066c4 100644
--- a/DEVELOPMENT.howto.md
+++ b/DEVELOPMENT.howto.md
@@ -1,54 +1,55 @@
 # Developing for Effcee
 
-Thank you for considering Effcee development!  Please make sure you review
+Thank you for considering Effcee development! Please make sure you review
 [`CONTRIBUTING.md`](CONTRIBUTING.md) for important preliminary info.
 
 ## Building
 
 Instructions for first-time building can be found in [`README.md`](README.md).
-Incremental build after a source change can be done using `ninja` (or
+Incremental build after a source change can be done using `bazel` or `ninja` (or
 `cmake --build`) and `ctest` exactly as in the first-time procedure.
 
 ## Issue tracking
 
-We use GitHub issues to track bugs, enhancement requests, and questions.
-See [the project's Issues page](https://github.com/google/effcee/issues).
+We use GitHub issues to track bugs, enhancement requests, and questions. See
+[the project's Issues page](https://github.com/google/effcee/issues).
 
 For all but the most trivial changes, we prefer that you file an issue before
-submitting a pull request.  An issue gives us context for your change: what
-problem are you solving, and why.  It also allows us to provide feedback on
-your proposed solution before you invest a lot of effort implementing it.
+submitting a pull request. An issue gives us context for your change: what
+problem are you solving, and why. It also allows us to provide feedback on your
+proposed solution before you invest a lot of effort implementing it.
 
 ## Code reviews
 
 All submissions are subject to review via the GitHub pull review process.
 Reviews will cover:
 
-* *Correctness:* Does it work?  Does it work in a multithreaded context?
-* *Testing:* New functionality should be accompanied by tests.
-* *Testability:* Can it easily be tested?  This is proven with accompanying tests.
-* *Design:* Is the solution fragile? Does it fit with the existing code?
-  Would it easily accommodate anticipated changes?
-* *Ease of use:* Can a client get their work done with a minimum of fuss?
-  Are there unnecessarily surprising details?
-* *Consistency:* Does it follow the style guidelines and the rest of the code?
-  Consistency reduces the work of future readers and maintainers.
-* *Portability:* Does it work in many environments?
+*   *Correctness:* Does it work? Does it work in a multithreaded context?
+*   *Testing:* New functionality should be accompanied by tests.
+*   *Testability:* Can it easily be tested? This is proven with accompanying
+    tests.
+*   *Design:* Is the solution fragile? Does it fit with the existing code? Would
+    it easily accommodate anticipated changes?
+*   *Ease of use:* Can a client get their work done with a minimum of fuss? Are
+    there unnecessarily surprising details?
+*   *Consistency:* Does it follow the style guidelines and the rest of the code?
+    Consistency reduces the work of future readers and maintainers.
+*   *Portability:* Does it work in many environments?
 
 To respond to feedback, submit one or more *new* commits to the pull request
 branch. The project maintainer will normally clean up the submission by
-squashing feedback response commits.  We maintain a linear commit history,
-so submission will be rebased onto master before merging.
+squashing feedback response commits. We maintain a linear commit history, so
+submission will be rebased onto master before merging.
 
 ## Testing
 
 There is a lot we won't say about testing. However:
 
-* Most tests should be small scale, i.e. unit tests.
-* Tests should run quickly.
-* A test should:
-  * Check a single behaviour.  This often corresponds to a use case.
-  * Have a three phase structure: setup, action, check.
+*   Most tests should be small scale, i.e. unit tests.
+*   Tests should run quickly.
+*   A test should:
+    *   Check a single behaviour. This often corresponds to a use case.
+    *   Have a three phase structure: setup, action, check.
 
 ## Coding style