| # The chrome/browser/api directory is for programming interfaces |
| # provided by Chrome to Browser Components that run within Chrome. |
| # Files here are not allowed to include stuff under chrome/browser |
| # since that would leak implementation details to users of the APIs. |
| # |
| # APIs can be either pure-virtual to allow specialization at runtime, |
| # or they can be non-virtual and specialized per platform (or |
| # otherwise at compile time), or a mix of non-virtual and virtual. |
| # The primary initial objective is to break Browser Components' |
| # dependencies on implementation details, so non-virtual classes in |
| # header files that do not expose any headers from chrome/browser |
| # except for chrome/browser/api are acceptable. |
| # |
| # Note that for non-virtual APIs, there is an increased risk of an |
| # implicit link-time dependency remaining from the user of the API to |
| # the implementation. We are accepting this risk initially, but plan |
| # to write a new type of link-time or target-level set of dependency |
| # rules to help us find such problems and reduce them over time. |
| # |
| # The directory structure under chrome/browser/api/ is a mirror of |
| # those parts of the chrome/browser/ structure that APIs have been |
| # extracted from. Hence, an API defined in chrome/browser/api/x/y/z |
| # is likely to be implemented in a directory chrome/browser/x/y/z. |
| # |
| # See http://www.chromium.org/developers/design-documents/browser-components |
| include_rules = [ |
| "-chrome/browser", |
| "+chrome/browser/api", |
| |
| # TODO(joi): Get rid of this. |
| "!chrome/browser/profiles/refcounted_profile_keyed_service.h", |
| ] |
| |
| specific_include_rules = { |
| ".*_[a-z]+test\.cc": [ |
| "+chrome/test", |
| ], |
| } |