README 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410
  1. documentation
  2. =============
  3. This is the directory that contains the Yocto Project documentation. The Yocto
  4. Project source repositories at https://git.yoctoproject.org/cgit.cgi have two
  5. instances of the "documentation" directory. You should understand each of
  6. these instances.
  7. poky/documentation - The directory within the poky Git repository containing
  8. the set of Yocto Project manuals. When you clone the
  9. poky Git repository, the documentation directory
  10. contains the manuals. The state of the manuals in this
  11. directory is guaranteed to reflect the latest Yocto
  12. Project release. The manuals at the tip of this
  13. directory will also likely contain most manual
  14. development changes.
  15. yocto-docs/documentation - The Git repository for the Yocto Project manuals.
  16. This repository is where manual development
  17. occurs. If you plan on contributing back to the
  18. Yocto Project documentation, you should set up
  19. a local Git repository based on this upstream
  20. repository as follows:
  21. git clone git://git.yoctoproject.org/yocto-docs
  22. Changes and patches are first pushed to the
  23. yocto-docs Git repository. Later, they make it
  24. into the poky Git repository found at
  25. git://git.yoctoproject.org/poky.
  26. Manual Organization
  27. ===================
  28. Here the folders corresponding to individual manuals:
  29. * brief-yoctoprojectqs - Yocto Project Quick Start
  30. * overview-manual - Yocto Project Overview and Concepts Manual
  31. * contributor-guide - Yocto Project and OpenEmbedded Contributor Guide
  32. * ref-manual - Yocto Project Reference Manual
  33. * bsp-guide - Yocto Project Board Support Package (BSP) Developer's Guide
  34. * dev-manual - Yocto Project Development Tasks Manual
  35. * kernel-dev - Yocto Project Linux Kernel Development Manual
  36. * profile-manual - Yocto Project Profiling and Tracing Manual
  37. * sdk-manual - Yocto Project Software Development Kit (SDK) Developer's Guide.
  38. * toaster-manual - Toaster User Manual
  39. * test-manual - Yocto Project Test Environment Manual
  40. * migration-guides - Yocto Project Release and Migration Notes
  41. Each folder is self-contained regarding content and figures.
  42. If you want to find HTML versions of the Yocto Project manuals on the web,
  43. the current versions reside at https://docs.yoctoproject.org.
  44. poky.yaml
  45. =========
  46. This file defines variables used for documentation production. The variables
  47. are used to define release pathnames, URLs for the published manuals, etc.
  48. standards.md
  49. ============
  50. This file specifies some rules to follow when contributing to the documentation.
  51. template/
  52. =========
  53. Contains a template.svg, to make it easier to create consistent
  54. SVG diagrams.
  55. Sphinx
  56. ======
  57. The Yocto Project documentation was migrated from the original DocBook
  58. format to Sphinx based documentation for the Yocto Project 3.2
  59. release. This section will provide additional information related to
  60. the Sphinx migration, and guidelines for developers willing to
  61. contribute to the Yocto Project documentation.
  62. Sphinx is a tool that makes it easy to create intelligent and
  63. beautiful documentation, written by Georg Brandl and licensed under
  64. the BSD license. It was originally created for the Python
  65. documentation.
  66. Extensive documentation is available on the Sphinx website:
  67. https://www.sphinx-doc.org/en/master/. Sphinx is designed to be
  68. extensible thanks to the ability to write our own custom extensions,
  69. as Python modules, which will be executed during the generation of the
  70. documentation.
  71. Yocto Project documentation website
  72. ===================================
  73. The website hosting the Yocto Project documentation, can be found
  74. at: https://docs.yoctoproject.org/.
  75. The entire Yocto Project documentation, as well as the BitBake manual,
  76. is published on this website, including all previously released
  77. versions. A version switcher was added, as a drop-down menu on the top
  78. of the page to switch back and forth between the various versions of
  79. the current active Yocto Project releases.
  80. Transition pages have been added (as rst files) to show links to old
  81. versions of the Yocto Project documentation with links to each manual
  82. generated with DocBook.
  83. How to build the Yocto Project documentation
  84. ============================================
  85. To build the documentation, you need Sphinx and a few other packages,
  86. which depend on your host GNU/Linux distribution. Such packages are listed on
  87. https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#required-packages-for-the-build-host
  88. To build the documentation locally, run:
  89. $ cd documentation
  90. $ make html
  91. The resulting HTML index page will be _build/html/index.html, and you
  92. can browse your own copy of the locally generated documentation with
  93. your browser.
  94. Alternatively, you can use Pipenv to automatically install all required
  95. dependencies in a virtual environment:
  96. $ cd documentation
  97. $ pipenv install
  98. $ pipenv run make html
  99. Style checking the Yocto Project documentation
  100. ==============================================
  101. The project is starting to use Vale (https://vale.sh/)
  102. to validate the text style.
  103. To install Vale:
  104. $ pip install vale
  105. To run Vale:
  106. $ make stylecheck
  107. Style checking the whole documentation might take some time and generate a
  108. lot of warnings/errors, thus one can run Vale on a subset of files or
  109. directories:
  110. $ make stylecheck VALEDOCS=<file>
  111. $ make stylecheck VALEDOCS="<file1> <file2>"
  112. $ make stylecheck VALEDOCS=<dir>
  113. Lint checking the Yocto Project documentation
  114. =============================================
  115. To fix errors which are not reported by Sphinx itself,
  116. the project uses sphinx-lint (https://github.com/sphinx-contrib/sphinx-lint).
  117. To install sphinx-lint:
  118. $ pip install sphinx-lint
  119. To run sphinx-lint:
  120. $ make sphinx-lint
  121. Lint checking the whole documentation might take some time and generate a
  122. lot of warnings/errors, thus one can run sphinx-lint on a subset of files
  123. or directories:
  124. $ make sphinx-lint SPHINXLINTDOCS=<file>
  125. $ make sphinx-lint SPHINXLINTDOCS="<file1> <file2>"
  126. $ make sphinx-lint SPHINXLINTDOCS=<dir>
  127. Sphinx theme and CSS customization
  128. ==================================
  129. The Yocto Project documentation is currently based on the "Read the
  130. Docs" Sphinx theme, with a few changes to make sure the look and feel
  131. of the project documentation is preserved.
  132. Most of the theme changes can be done using the file
  133. 'sphinx-static/theme_overrides.css'. Most CSS changes in this file
  134. were inherited from the DocBook CSS stylesheets.
  135. Sphinx design guidelines and principles
  136. =======================================
  137. The initial Docbook to Sphinx migration was done with an automated
  138. tool called Pandoc (https://pandoc.org/). The tool produced some clean
  139. output markdown text files. After the initial automated conversion
  140. additional changes were done to fix up headings, images and links. In
  141. addition Sphinx has built in mechanisms (directives) which were used
  142. to replace similar functions implemented in Docbook such as glossary,
  143. variables substitutions, notes and references.
  144. Headings
  145. ========
  146. The layout of the Yocto Project manuals is organized as follows
  147. Book
  148. Chapter
  149. Section
  150. Subsection
  151. Subsubsection
  152. Subsubsubsection
  153. Here are the heading styles that we use in the manuals:
  154. Book => overline ===
  155. Chapter => overline ***
  156. Section => ====
  157. Subsection => ----
  158. Subsubsection => ~~~~
  159. Subsubsubsection => ^^^^
  160. With this proposal, we preserve the same TOCs between Sphinx and Docbook.
  161. Built-in glossary
  162. =================
  163. Sphinx has a glossary directive. From
  164. https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#glossary:
  165. This directive must contain a reST definition list with terms and
  166. definitions. It's then possible to refer to each definition through the
  167. [https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-term
  168. 'term' role].
  169. So anywhere in any of the Yocto Project manuals, :term:`VAR` can be
  170. used to refer to an item from the glossary, and a link is created
  171. automatically. A general index of terms is also generated by Sphinx
  172. automatically.
  173. Global substitutions
  174. ====================
  175. The Yocto Project documentation makes heavy use of global
  176. variables. In Docbook these variables are stored in the file
  177. poky.ent. This Docbook feature is not handled automatically with
  178. Pandoc. Sphinx has builtin support for substitutions
  179. (https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#substitutions),
  180. however there are important shortcomings. For example they cannot be
  181. used/nested inside code-block sections.
  182. A Sphinx extension was implemented to support variable substitutions
  183. to mimic the DocBook based documentation behavior. Variable
  184. substitutions are done while reading/parsing the .rst files. The
  185. pattern for variables substitutions is the same as with DocBook,
  186. e.g. `&VAR;`.
  187. The implementation of the extension can be found here in the file
  188. documentation/sphinx/yocto-vars.py, this extension is enabled by
  189. default when building the Yocto Project documentation. All variables
  190. are set in a file call poky.yaml, which was initially generated from
  191. poky.ent. The file was converted into YAML so that it is easier to
  192. process by the custom Sphinx extension (which is a Python module).
  193. For example, the following .rst content will produce the 'expected'
  194. content:
  195. .. code-block::
  196. $ mkdir poky-&DISTRO;
  197. or
  198. $ git clone &YOCTO_GIT_URL;/git/poky -b &DISTRO_NAME_NO_CAP;
  199. Variables can be nested, like it was the case for DocBook:
  200. YOCTO_HOME_URL : "https://www.yoctoproject.org"
  201. YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs"
  202. Note directive
  203. ==============
  204. Sphinx has a builtin 'note' directive that produces clean Note section
  205. in the output file. There are various types of directives such as
  206. "attention", "caution", "danger", "error", "hint", "important", "tip",
  207. "warning", "admonition" that are supported, and additional directives
  208. can be added as Sphinx extension if needed.
  209. Figures
  210. =======
  211. The Yocto Project documentation has many figures/images. Sphinx has a
  212. 'figure' directive which is straightforward to use. To include a
  213. figure in the body of the documentation:
  214. .. image:: figures/YP-flow-diagram.png
  215. Links and References
  216. ====================
  217. The following types of links can be used: links to other locations in
  218. the same document, to locations in other documents and to external
  219. websites.
  220. More information can be found here:
  221. https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html.
  222. For external links, we use this syntax:
  223. `link text <link URL>`__
  224. instead of:
  225. `link text <link URL>`_
  226. Both syntaxes work, but the latter also creates a "link text" reference
  227. target which could conflict with other references with the same name.
  228. So, only use this variant when you wish to make multiple references
  229. to this link, reusing only the target name.
  230. See https://stackoverflow.com/questions/27420317/restructured-text-rst-http-links-underscore-vs-use
  231. Anchor (<#link>) links are forbidden as they are not checked by Sphinx during
  232. the build and may be broken without knowing about it.
  233. References
  234. ==========
  235. The following extension is enabled by default:
  236. sphinx.ext.autosectionlabel
  237. (https://www.sphinx-doc.org/en/master/usage/extensions/autosectionlabel.html).
  238. This extension allows you to refer sections by their titles. Note that
  239. autosectionlabel_prefix_document is enabled by default, so that we can
  240. insert references from any document.
  241. For example, to insert an HTML link to a section from
  242. documentation/manual/intro.rst, use:
  243. Please check this :ref:`manual/intro:Cross-References to Locations in the Same Document`
  244. Alternatively a custom text can be used instead of using the section
  245. text:
  246. Please check this :ref:`section <manual/intro:Cross-References to Locations in the Same Document>`
  247. TIP: The following command can be used to dump all the references that
  248. are defined in the project documentation:
  249. python -msphinx.ext.intersphinx <path to build folder>/html/objects.inv
  250. This dump contains all links and for each link it shows the default
  251. "Link Text" that Sphinx would use. If the default link text is not
  252. appropriate, a custom link text can be used in the ':ref:' directive.
  253. Extlinks
  254. ========
  255. The sphinx.ext.extlinks extension is enabled by default
  256. (https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html#use-the-external-links-extension),
  257. and it is configured with the 'extlinks' definitions in
  258. the 'documentation/conf.py' file:
  259. 'yocto_home': ('https://yoctoproject.org%s', None),
  260. 'yocto_wiki': ('https://wiki.yoctoproject.org%s', None),
  261. 'yocto_dl': ('https://downloads.yoctoproject.org%s', None),
  262. 'yocto_lists': ('https://lists.yoctoproject.org%s', None),
  263. 'yocto_bugs': ('https://bugzilla.yoctoproject.org%s', None),
  264. 'yocto_ab': ('https://autobuilder.yoctoproject.org%s', None),
  265. 'yocto_docs': ('https://docs.yoctoproject.org%s', None),
  266. 'yocto_git': ('https://git.yoctoproject.org%s', None),
  267. 'oe_home': ('https://www.openembedded.org%s', None),
  268. 'oe_lists': ('https://lists.openembedded.org%s', None),
  269. 'oe_git': ('https://git.openembedded.org%s', None),
  270. 'oe_wiki': ('https://www.openembedded.org/wiki%s', None),
  271. 'oe_layerindex': ('https://layers.openembedded.org%s', None),
  272. 'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None),
  273. It creates convenient shortcuts which can be used throughout the
  274. documentation rst files, as:
  275. Please check this :yocto_wiki:`wiki page </Weekly_Status>`
  276. Intersphinx links
  277. =================
  278. The sphinx.ext.intersphinx extension is enabled by default
  279. (https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html),
  280. so that we can cross reference content from other Sphinx based
  281. documentation projects, such as the BitBake manual.
  282. References to the BitBake manual can directly be done:
  283. - With a specific description instead of the section name:
  284. :ref:`Azure Storage fetcher (az://) <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
  285. - With the section name:
  286. :ref:`bitbake-user-manual/bitbake-user-manual-intro:usage and syntax` option
  287. If you want to refer to an entire document (or chapter) in the BitBake manual,
  288. you have to use the ":doc:" macro with the "bitbake:" prefix:
  289. - :doc:`BitBake User Manual <bitbake:index>`
  290. - :doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter
  291. Note that a reference to a variable (:term:`VARIABLE`) automatically points to
  292. the BitBake manual if the variable is not described in the Reference Manual's Variable Glossary.
  293. However, if you need to bypass this, you can explicitely refer to a description in the
  294. BitBake manual as follows:
  295. :term:`bitbake:BB_NUMBER_PARSE_THREADS`
  296. This would be the same if we had identical document filenames in
  297. both the Yocto Project and BitBake manuals:
  298. :ref:`bitbake:directory/file:section title`
  299. Submitting documentation changes
  300. ================================
  301. Please see the top level README file in this repository for details of where
  302. to send patches.