weston/doc/sphinx/toc/libweston.rst
Marius Vlad bbf6ea0b4f build: Add sphinx/breathe support for generating documentation
This is adds basic configuration files for doxygen and for breathe,
which is a doxygen-to-sphinx bridge that can document C symbols.

Breathe is configured with default project 'weston' and implicitly adds
:members: and :undoc-members: to breathe configuration options.
This allows a shorter way to call breathe directives without the need
specify the project and also to display implicitly all the members,
documented or not.

A 'docs' run_target to force the docs to be re-built has been added.
Initially (the first time the build system is ran) the documentation
will automatically be built, but later re-builds will require the use of
the 'docs' target. This avoid further delays in building weston but in
the same time allows the possiblity to update/improve the documentation
bits to those who want that.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-06-25 14:05:54 +00:00

47 lines
2.0 KiB
ReStructuredText

Libweston
=========
.. toctree::
:maxdepth: 2
:caption: Contents:
libweston/compositor.rst
libweston/head.rst
libweston/output.rst
`Libweston` is an effort to separate the re-usable parts of Weston into a
library. `Libweston` provides most of the boring and tedious bits of correctly
implementing core Wayland protocols and interfacing with input and output
systems, so that people who just want to write a new "Wayland window manager"
(WM) or a small desktop environment (DE) can focus on the WM part.
Libweston was first introduced in Weston 1.12, and is expected to continue
evolving through many Weston releases before it achieves a stable API and
feature completeness.
`Libweston`'s primary purpose is exporting an API for creating Wayland
compositors. Libweston's secondary purpose is to export the weston_config API
so that third party plugins and helper programs can read :file:`weston.ini` if
they want to. However, these two scopes are orthogonal and independent. At no
point will the compositor functionality use or depend on the weston_config
functionality.
Further work
------------
In current form, `libweston` is an amalgam of various APIs mashed together and
currently it needs a large clean-up and re-organization and possibly, a split
into class-specific files. The documentation only provide the public
API and not the private API used inside `libweston` or other functionality
required in the core internals of the library.
With that in mind we see the following steps needed to achieve that:
- migrate everything that should not reside in the public API (for instance,
the doxygen **\\internal** command is a clear indication that that symbol
should not be present in the public API) to private headers.
- if needed be, create class-specific files, like **input** and **output**
which should tackle specific functionality, and allows to write the
documentation parts much easier, and provides clarity for `libweston`
users when they'd read it.