After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782176 - meson: gstreamer-plugins docs are missing
meson: gstreamer-plugins docs are missing
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 796870 (view as bug list)
Depends on:
Reported: 2017-05-04 19:04 UTC by Jan Alexander Steffens (heftig)
Modified: 2018-11-03 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Jan Alexander Steffens (heftig) 2017-05-04 19:04:42 UTC
When building with meson, the gstreamer-plugins-1.0 docs are missing.
Comment 1 Thibault Saunier 2017-05-04 20:59:16 UTC
This is a known and not so simple to fix issue as currently the plugins generation system is quite linked to autotools.

Instead I am porting GStreamer documentation to hotdoc[0] on my `hotdoc` branches around here[1].

You can find the current result here:

It is almost done but I have patches to get merged in hotdoc and need to fix some details all around still, we are planning to discuss that work for the GStreamer hackfest in two weeks :-)

Comment 2 Tim-Philipp Müller 2018-07-25 07:53:25 UTC
*** Bug 796870 has been marked as a duplicate of this bug. ***
Comment 3 Thibault Saunier 2018-08-14 17:40:41 UTC
I updated that port to hotdoc, we got a pre-release of the required Hotdoc out I proposed the hotdoc meson module upstream already (hopefully it gets merged soon :-)) and I have the rendered documentation here:

Would be nice if you could have a look and let me know what you think what else you would like etc...

The GStreamer branch are still at the same place (and are quite clean/ready to be merged).
Comment 4 Tim-Philipp Müller 2018-08-14 18:37:40 UTC
> The GStreamer branch are still at the same place (and are quite
> clean/ready to be merged).

Could you link the repo/branch you are refering to? The "hotdoc+plugins" branch on your gstreamer core github does not look very clean :)
Comment 5 Tim-Philipp Müller 2018-08-14 18:44:04 UTC
You mean ?
Comment 7 Thibault Saunier 2018-08-14 18:59:49 UTC
Ah, I haven't removed gtk-doc support, I think we can keep having them until we have autotools support, not sure what you prefer?
Comment 8 Tim-Philipp Müller 2018-08-14 19:15:39 UTC
I'm a bit confused looking at the repos (e.g. gstreamer/hotdoc) - what's the plan exactly?

My plan was to move *everything* docs related including API/plugin docs generation into the gst-docs module.

This requires a few things beside the api ref / plugin ref generation, such as also generating a devhelp version of all the docs in addition to html (but aiui that's already possible?)

And then we ship a gst-docs tarball basically.

We would remove gtk-doc stuff from the other modules when we drop autotools.

But we will not add hotdoc support to the other modules as I see it.
Comment 9 Thibault Saunier 2018-08-14 19:35:12 UTC
Well, the doc still is in each repo and can be built separately, gst-docs is just aggregating everything in one place.

Shipping a gst-docs tarball is easy to do with that setup.

The hotdoc/ directory is just where I have the infos about the plugins and the definition of how to build the doc for plugins/libs basically, that info is reused (through meson subproject goodness) in gst-docs to generate a coherent doc for all modules. Currently `ninja -C build/ install`  install the doc for each module, I can revert that part if you think it is better to just "advertise" the aggregated doc and distribute it in a tarball separetly (I think that would be a good idea in the end).

Now the way it is done is also good so that when developing in -good for example you will be able to generated the doc for the plugin you care (to check) with ninja -C build docs/hotdoc/thepluginicareabout-doc

Makes sense?
Comment 10 Thibault Saunier 2018-08-14 22:53:35 UTC
So this is basically the infrastructure and how things work together currently:

In each module, we have a set of Hotdoc meson targets which build docs for different components (1 per lib and 1 per plugin). Those are referenced by the `libs_doc` and `plugins_doc` variables in the meson file so they can be reused/referenced from outside the module (be aggregated in gst-docs).

In gst-build we have a list of built projects which is passed to gst-docs.

In gst-docs, we go over the list of built subprojects and retrieve the targets for all the doc from the various subprojects, aggregating the documentation in a single sitemap.


To build the GStreamer plugins documenation we have a `hotdoc-plugin-inspect` binary which basically takes a list of plugins `.so` and outputs json. Then we have a hotdoc-plugin that consumes the json, updates it with informations from previous runs (I worked on making sure it is all ordered and stable) and renders the documentation for the plugins. The json file doesn't contain the doc from comments. Currently updating the json is done at the same time as building the doc, it can easily be done in a dedicated run_target if required/preferred (I am not sure it is a good idea).
Comment 11 Thibault Saunier 2018-08-15 18:06:18 UTC
I added a `release` target that generates a tarball like: - it contains all the doc and required files to be used inside devhelp.
Comment 12 Thibault Saunier 2018-10-22 11:58:22 UTC
I just cleaned up the branches and I think it is almost ready for merging now. Would be nice if someone could review.

(List of branches is available in comment 6:
Comment 13 GStreamer system administrator 2018-11-03 12:40:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: