mojo/public: Include gtest.h as "gtest/gtest.h", instead of via "absolute" path.

* This allows one to put gtest in other places (e.g., as in the fuchsia
  mojo repo).
* Thus this allows merges to the fuchsia mojo repo to happen much more
  cleanly. (I.e., nearly all files will be unchanged.)
* Why does this necessarily work? gtest.h itself includes other things
  in gtest's |include| directory in the same way, so gtest's |include|
  directory better be in the include path whenever gtest is used.
* Why "gtest/gtest.h" and not <gtest/gtest.h>? i. It's not a system
  header. ii. It's not a C header (which all other .h files included
  using <...> are). iii. It's the way gtest (in particular gtest.h)
  itself includes its own headers.

Also, make a "forwarding" //mojo/public:gtest target, so that other
things in //mojo/public can use gtest without needing to know directly
where gtest is. (This again simplifies merges to the fuchsia mojo repo,
as well as making it easier to consume/build the public tests from

Review URL: .

Cr-Mirrored-Commit: dddc0e5845959fe485ec11fc94bfecc4a4807562
78 files changed
tree: 76173acc806c5c6a33ff09bf04c8923bd50ab28e
  1. build/
  2. c/
  3. cpp/
  4. dart/
  5. go/
  6. interfaces/
  7. java/
  8. js/
  9. platform/
  10. python/
  11. rust/
  12. third_party/
  13. tools/
  14. .gitignore
  17. mojo.gni
  18. mojo_application.gni
  19. mojo_sdk.gni

Mojo Public API

The Mojo Public API is a binary stable API to the Mojo system.

It consists of support for a number of programming languages (with a directory for each support language), some “build” tools and build-time requirements, and interface definitions for Mojo services (specified using an IDL).

Note that there are various subdirectories named tests/. These contain tests of the code in the enclosing directory, and are not meant for use by Mojo applications.


The c/, cpp/, js/ subdirectories define the API for C, C++, and JavaScript, respectively.

The basic principle for these directories is that they consist of the source files that one needs at build/deployment/run time (as appropriate for the language), organized in a natural way for the particular language.


The interfaces/ subdirectory contains Mojo IDL (a.k.a. .mojom) descriptions of standard Mojo services.


The platform/ subdirectory contains any build-time requirements (e.g., static libraries) that may be needed to produce a Mojo application for certain platforms, such as a native shared library or as a NaCl binary.


The tools/ subdirectory contains tools that are useful/necessary at build/deployment time. These tools may be needed (as a practical necessity) to use the API in any given language, e.g., to generate bindings from Mojo IDL files.