|author||Viet-Trung Luu <email@example.com>||Thu Aug 11 23:43:59 2016|
|committer||Viet-Trung Luu <firstname.lastname@example.org>||Thu Aug 11 23:43:59 2016|
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 elsewhere.) Remail@example.com Review URL: https://codereview.chromium.org/2244503002 . Cr-Mirrored-From: https://github.com/domokit/mojo Cr-Mirrored-Commit: dddc0e5845959fe485ec11fc94bfecc4a4807562
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 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.