commit | 41d9e66565659d1e6b45561be93fdc17ef0bf127 | [log] [tgz] |
---|---|---|
author | Viet-Trung Luu <viettrungluu@chromium.org> | Thu Aug 11 23:43:59 2016 |
committer | Viet-Trung Luu <viettrungluu@chromium.org> | Thu Aug 11 23:43:59 2016 |
tree | 76173acc806c5c6a33ff09bf04c8923bd50ab28e | |
parent | 7436036319b8b9ccb5c9da3fcac7b9b940fe8794 [diff] |
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.) R=vardhan@google.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 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.