Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 This directory is for components that have the Content Module as the | |
| 2 uppermost layer they depend on. They may depend only on the Content | |
| 3 API (content/public) and on lower layers (e.g. base/, net/, ipc/ | |
| 4 etc.). | |
| 5 | |
| 6 These components are not part of the Content Module itself. They are | |
| 7 built in a separate .gyp file (content_components.gyp in this | |
| 8 directory). | |
| 9 | |
| 10 Components that have bits of code that need to live in different | |
| 11 processes (e.g. some code in the browser process, some in the renderer | |
| 12 process, etc.) should separate the code into different subdirectories. | |
| 13 Hence for a component named 'foo' you might end up with a structure | |
| 14 like the following: | |
| 15 | |
| 16 content/components/foo - DEPS, OWNERS, foo.gypi | |
| 17 content/components/foo/browser - code that needs the browser process | |
| 18 content/components/foo/common - for e.g. IPC constants and such | |
| 19 content/components/foo/renderer - code that needs renderer process | |
| 20 content/components/foo/java - Android code | |
|
darin (slow to review)
2012/10/30 18:18:25
One of these is not like the others. Why is java
| |
| 21 | |
| 22 These subdirectories should have DEPS files with the relevant | |
| 23 restrictions in place, e.g. only content/components/foo/browser should | |
| 24 be allowed to #include from content/public/browser. | |
|
John Knottenbelt
2012/10/30 18:48:29
Please could you add a statement on what C++ names
| |
| OLD | NEW |