gstreamer/subprojects/gstreamer/docs
Mathieu Duponchelle 2f020013e6 docs: explicitly declare gir build dependencies
As the path to the gir file is passed to hotdoc.generate_doc() and
not the build target itself, meson doesn't know about the dependency.

In turn, as the CI doesn't build everything before building the
documentation target, some gir files might not exist, for instance
in the case of gst-rtsp-server, causing the output documentation to
be empty.

The error occurred silently because hotdoc accepts wildcards for
*-sources arguments, thus it won't warn about a missing gir file as
it is legitimate for glob matching to resolve to nothing.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3686>
2023-01-06 22:50:57 +00:00
..
gst Remove the uninstalled term 2022-03-01 11:33:10 +00:00
images Move files from gstreamer into the "subprojects/gstreamer/" subdir 2021-09-24 16:13:07 -03:00
libs Move files from gstreamer into the "subprojects/gstreamer/" subdir 2021-09-24 16:13:07 -03:00
plugins inputselector: Add drop-backwards property 2022-11-22 21:21:40 +02:00
random Remove ChangeLog files from git repository 2022-12-04 18:16:25 +00:00
gst-hotdoc-plugins-scanner.c docs: plugins-scanner: Handle interface used for plugin API properties 2022-10-21 09:14:25 +00:00
gst-plugins-doc-cache-generator.py Move files from gstreamer into the "subprojects/gstreamer/" subdir 2021-09-24 16:13:07 -03:00
index.md Remove the uninstalled term 2022-03-01 11:33:10 +00:00
meson.build docs: explicitly declare gir build dependencies 2023-01-06 22:50:57 +00:00
README Move files from gstreamer into the "subprojects/gstreamer/" subdir 2021-09-24 16:13:07 -03:00
version.in Move files from gstreamer into the "subprojects/gstreamer/" subdir 2021-09-24 16:13:07 -03:00

GStreamer documentation notes

OVERVIEW
========

Our documentation uses hotdoc, you should usually refer to the
[hotdoc documentation](http://hotdoc.github.io/).

GStreamer has two sets of documentation but both are controlled and aggregated in
the `gst-docs` module:

* API references, using hotdoc (gstreamer, gstreamer-libs) - maintained
  in each GStreamer modules repository
* FAQ / Application Development Manual / Plugin Writer's Guide / Tutorials -
  these are maintained in markdown format and live in the gst-docs repository.

To build the full documentation you should make sure to have `hotdoc` installed and
build [gst-build](https://cgit.freedesktop.org/gstreamer/gst-build/) configuring it with:

```
meson -Ddoc=enabled build/
```

And building the documentation:

```
ninja -C build/ subprojects/gst-docs/GStreamer-doc`, this will result in two documentation sets:
```

This will generate two outputs:

  - the html in `build/subprojects/gst-docs/GStreamer-doc/html`
  - the [devhelp](https://wiki.gnome.org/Apps/Devhelp) in `build/subprojects/gst-docs/GStreamer-doc/devhelp`

HOW THE BUILD SYSTEM IS SET UP
------------------------------
Hotdoc build targets are generated for each documentation 'components' (ie. hotdoc
subprojects). This includes libraries documentation and one target per GStreamer plugin.

One can build a specific documentation target by explicitly building the target,
for example to build the GStreamer core library documentation (adapt the paths if you
are using `gst-build`):

    ninja docs/libgstreamer-doc

Then the documentation will be available in `docs/libgstreamer-doc/html/`.

SPELL CHECKING
--------------

FILL ME.

HOTDOC NOTES
=============

* files under revision control:
  - sitemap.txt: defines the overall structure of the documentation
  - gst_plugins_cache.json: Automatically generated information about plugins

* what to do when adding a new piece of API:
  - Just let hotdoc generate the documentation and decide where to put it
  - Make sure to add a `SECTION` documentation section in the file where
    the documentation should land (hotdoc will use that to create its
    "smart index" and list symbols from other files that should land
    on that page in that section.
  - document functions, signals in the .c files
  - document structs, typedefs, enums in the .h files

* what to do when trying to improve the docs
  - compare the output of
    grep "_get_type" gstreamer-sections.txt | sort
    with the types in XXX.types to detect entries that
    are maybe missing
  - hotdoc does not warns about empty member docs!, run
    find . -name "*.[c,h]" -exec egrep -Hn "^ +\* +@.*: *$" {} \;
    in the project root to find them
  - hotdoc does not warns about empty Returns: docs!, run
    find . -name "*.[c,h]" -exec egrep -Hn "^ +\* +@Returns: *$" {} \;
    in the project root to find them

* what happens during a hotdoc build ?
  - Read the GIR and scan the sources files for the docstrings and
    generate the documentation laying out pages the way they are documented.
  - The meson build definition is set in a way that makes it so all plugins
    in `plugins_doc` are introspected and documented

STYLE GUIDE FOR HOTDOC
=======================
- this is in addition to gtk-doc's style-guide.txt

- function/macro descriptions are descriptive, not imperative
  ie, it uses the third person verb
- synopsis and description should have most-used/application functions at the
  top
- functions that can return FALSE/NULL or fail should describe their failure
  conditions like this:
  * Returns NULL if no element with the given name is found in the bin, if
  * the frobble was stuck in the froob, or the frizzle was frazzed.
- a line with function attributes should be added before Returns:
  - can contain:
    "MT safe." - the function is verified to be multithreadingsafe
    "Caller owns returned reference" for refcounted classes
    "Caller owns returned value" for other types (iterators, ..)
  - we do this because, in contrast with GLib/GTK, we are more explicit
    about threadsafety and related issues

WEBSITE DOCUMENTATION
=====================

Updating the online documentation is done from with the `gst-docs` repository

DOCUMENTING ELEMENTS
====================
A hotdoc plugin is provided by GStreamer to document GStreamer plugins.

- to add a plugin to be documented:
  - make sure the plugin is added to the `plugins_doc` variable in meson
- to add an element to be documented:
  - add a gtk-doc section to the source code like:
/**
 * SECTION:element-multifdsink

  and fill it with documentation about the element
  - add an example:
    - either a few pipelines, inside a codeblock
    - or a piece of code inside a codeblock or in `tests/examples/(pluginname)`
  - to build the doc for a plugin, do:
    `ninja docs/(pluginname)-doc`


DEVHELP INTEGRATION
-------------------
Check https://wiki.gnome.org/Apps/Devhelp
It's a really nice development app allowing you to look up API stuff
from various hotdoc/gtk-doc'd libraries.  GStreamer is one of these ;)

hotdoc generates both html API docs and the matching .devhelp(2) books.

IMAGES
------
It's important to keep the original source format for images, to be able
to change and regenerate later on.  Original files go in
docs/images