Documentation — NuttX latest documentation (original) (raw)

The Apache NuttX Documentation is built using theSphinx documentation system. Documentation is written in ReStructured Text (RST), with Sphinx-specific directives. RST is the format used forPython documentation and is also used in many other projects. Using Sphinx, the RST files are rendered into HTML files that can be read in your browser.

Building

To render the Documentation locally, you should clone the NuttX main repository and navigate into it. Then,

1. Install Sphinx and other dependencies using pipenv. You may also find it helpful on platforms such as Windows and MacOS to use _pyenv_to manage your python installation. You can read about installing that on the project site.

$ pip3 install pipenv $ cd Documentation/ $ # install the dependencies into a virtual environment $ pipenv install $ # activate the virtual environment $ pipenv shell

1. Build documentation:

The resulting HTMLs will end up under _build/html. You can open your browser at the root with:

$ xdg-open _build/html/index.html

Live Rebuild

For more comfortable editing and previewing of changes (as make html will perform a slower full rebuild), you can install sphinx-autobuild which will monitor file changes and rebuild only affected files. To install it (within the virtual environment):

$ pip3 install sphinx-autobuild

To run:

Which will perform an initial clean build and monitor changes from then on.

Contributing

Contributions to documentation are appreciated. These can be as simple as fixing a typo or formatting issues to more involved changes such as documenting parts of NuttX which are not yet covered or even writing guides for other users.

The contribution workflow is the same as for the code, so check the Development Workflow to understand how your changes should be upstreamed.

Writing ReStructure Text with Sphinx

The following links can be used to learn about RST syntax and about Sphinx specific directives. Note that sometimes Sphinx’s approach is used over standard RST since it is more powerful (e.g. standard linking vs Sphinx:ref: which can be used across files, code-block directive vs :: which allows specifying highlight language, etc.):

• Sphinx documentation system
• ReStructured Text documentation
• Sphinx Guide to ReStructured Text
• Restructured Text cheat sheet

Documentation Conventions

While RST/Sphinx provide many ways to do things, it is best to follow a given convention to maintain consistency and avoid pitfalls. For this reason, documentation changes should follow the following set of conventions.

Indentation

Child blocks should be indented two-spaces. This includes itemizations/enumerations.

Headings

Three levels of headings should be used in general. The style used to mark sections is based around = and -. Sections should look like this:

================= Top Level Heading

Subsection

Subsubsection

Code

Code should be documented using the C domain. This means for example that a function should be documented as:

.. c:function:: bool myfunction(int arg1, int arg2)

Here the function should be described

:param arg1: Description of arg1 :param arg2: Description of arg2

:return: Description of return value

To document a piece of code, use a code-block directive, specifying the highlight language. If the block is not of code but some verbatim piece of text, it is acceptable to use RST standard ::. This is specially useful and compact when used in the following mode:

The text file should have the following content::

Line1 Line2 Line3

Linking

To generate internal links, Sphinx’s roles should be used. So, use :ref: instead of standard RST syntax like `link <target>`_ for internal links. If the target is in a different file, you can refer it with: :ref:`link text </pathtorst:Section Name>`.

Linking to a specific document can be done with :doc:`/path/to/document` (without .rst extension).

Notes and TODOS

Use RST admonitions to highlight things from the text, such as a note that should be prominently displayed.

In case you need to leave a TODO note in the documentation to point that something needs to be improved, use a todo admonition, which is available via the sphinx.ext.todo extension. This will let the reader of the documentation also know that the documentation is not yet finished somewhere and may further motivate a contribution.

Tags

Use the tag admonition from sphinx-tags to tag your pages appropriately. This makes it easier for users to search and index the documentation. There are some tags which should always be included:

• chip:* tags are for board/chip documentation, to indicate which boards use which chip
• experimental tags for boards/features that are experimental and should not be considered stable
• Tags with the names of supported peripherals can be included for boards too, like wifi and ethernet

Include the tags directive at the top of the page, with comma separators for each tag listed.

User Indications

To indicate a keypress, menu action or GUI button selection, use the following:

Go into menu :menuselection:File --> Save As, click :guilabel:&OK or press :kbd:Enter.

which would render as:

Go into menu , click OK or press Enter.

Tabbed examples

To indicate different instructions/examples for different scenarios (for example, different Operating Systems) use the tabs extension (see link for examples).

Tips

Spacing

If you are getting formatting errors, be sure to provide the appropriate spacing between a directive and its content. Generally, you should follow this format:

.. directive::

child content

non-child content which appears after previous directive

Note the line between directive and content and the indentation.