gtk-doc issueshttps://gitlab.gnome.org/GNOME/gtk-doc/-/issues2024-03-02T22:18:24Zhttps://gitlab.gnome.org/GNOME/gtk-doc/-/issues/153GitLab CI: update and re-enable it2024-03-02T22:18:24ZswilmetGitLab CI: update and re-enable itGitLab CI: review and update it.
Currently the GitLab CI fails because the Meson version provided is not recent enough:
```
ERROR: Meson version is 0.50.0 but project requires >= 0.51.
```
From https://gitlab.gnome.org/GNOME/gtk-doc/-...GitLab CI: review and update it.
Currently the GitLab CI fails because the Meson version provided is not recent enough:
```
ERROR: Meson version is 0.50.0 but project requires >= 0.51.
```
From https://gitlab.gnome.org/GNOME/gtk-doc/-/jobs/3642733
The GitLab CI of gtk-doc has not been updated for a while, so an update is required.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/91Cannot parse `typedef struct\n{`2019-07-12T04:42:59ZXavier Claessensxclaesse@gmail.comCannot parse `typedef struct\n{`If there is a newline before the struct block, gtkdoc will claim Foo is undeclared.
```c
typedef struct
{
int plop;
} Foo;
```If there is a newline before the struct block, gtkdoc will claim Foo is undeclared.
```c
typedef struct
{
int plop;
} Foo;
```https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/70cmake: support for flavour=no-xslt2018-11-30T12:06:59ZStefan Sauercmake: support for flavour=no-xsltThe git-version has changes for autotools that let you do
GTK_DOC_CHECK([1.29],[--flavour no-xslt])
to run with gtkdoc-mkhtml2 instead of gtkdoc-mkhtml+gtkdoc-fixxref. This needs support for cmake too.The git-version has changes for autotools that let you do
GTK_DOC_CHECK([1.29],[--flavour no-xslt])
to run with gtkdoc-mkhtml2 instead of gtkdoc-mkhtml+gtkdoc-fixxref. This needs support for cmake too.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/69refactor code for intermediate files2018-12-14T20:59:51ZStefan Sauerrefactor code for intermediate filesgtkdoc-scan and gtkdoc-scangobj produce a bunch of intermediate files (see https://gitlab.gnome.org/GNOME/gtk-doc/blob/master/doc/gtkdoc.dot) in a homegrown format. The biggest downside is that gtkdoc-mkdb needs to parse those files agai...gtkdoc-scan and gtkdoc-scangobj produce a bunch of intermediate files (see https://gitlab.gnome.org/GNOME/gtk-doc/blob/master/doc/gtkdoc.dot) in a homegrown format. The biggest downside is that gtkdoc-mkdb needs to parse those files again, which is a large part of the code there. Also the way it is done is to put most of the data into a large number of global lists and dictionaries, which in turn makes testing hard.
we should:
1) change gtkdoc-scan and gtkdoc-scangobj to produce json files (ideally just one file for each tool). This is relative simple since writing the files is mostly printf() (gtkdoc-scangobj is producing the data from .c code). Another option would be to produce one scan file per header. This would enable incremental scans (only scan the h-files that are newer that the scan-result file).
2) refactor gtkdoc-mkdb to simply load the json, this is more work since we need to replace all references in the code
A possible transition could be to design a new datastructure and fix the parsers in gtkdoc-mkdb to build that, then change the output for gtkdoc-scan and gtkdoc-scangobj and replace the parsers.
It would be awesome if someone would help with this.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/68allow passing parameters to gtkdoc-check and only grep them from Makefile as ...2018-11-30T11:45:41ZStefan Sauerallow passing parameters to gtkdoc-check and only grep them from Makefile as a fallbackEventually, it would be nice if `gtkdoc-check` accepted command line parameters more naturally, and only fell back to environment variables and reading `Makefile.am` if the command line parameters weren’t passed — but I don’t have time t...Eventually, it would be nice if `gtkdoc-check` accepted command line parameters more naturally, and only fell back to environment variables and reading `Makefile.am` if the command line parameters weren’t passed — but I don’t have time to work on that (sorry).
In my mind, something like the following would be good:
```
gtkdoc-check $builddir/path/to/docs $doc_module $doc_main_xml_file
```
(Copied from https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/18)https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/67Support TAP output from gtkdoc-check2018-11-30T11:45:22ZPhilip WithnallSupport TAP output from gtkdoc-check`gtkdoc-check` would be a bit easier to integrate into various common test harnesses if it (optionally) outputted in [TAP format](https://testanything.org/). Utilities like `gtester` support this when run with a `--tap` option, so it wou...`gtkdoc-check` would be a bit easier to integrate into various common test harnesses if it (optionally) outputted in [TAP format](https://testanything.org/). Utilities like `gtester` support this when run with a `--tap` option, so it would be consistent if `gtkdoc-check --tap` did the same.
The advantage of TAP output is that it provides a structured way to output the success/failure and details of each test being run by the test suite, so that the test harness which is calling `gtkdoc-check` can be aware of the individual unit tests and add them to overall stats correctly.
In the case of `gtkdoc-check`, I guess there’s one unit test for the `undeclared` symbol, one for `undocumented`, one for `unused`, etc.
See also: #66. In TAP format, log output has to be printed with a leading `# `, because other lines are interpreted as TAP commands.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/66Print out contents of *-{undocumented,unused,undeclared}.txt in gtkdoc-check ...2020-01-03T16:07:51ZPhilip WithnallPrint out contents of *-{undocumented,unused,undeclared}.txt in gtkdoc-check outputIt would be useful if the contents of the `*-{undocumented,unused,undeclared}.txt` files were printed by `gtkdoc-check` on failure, so that they end up in build logs. This could be conditional on (e.g.) passing `--verbose` to `gtkdoc-che...It would be useful if the contents of the `*-{undocumented,unused,undeclared}.txt` files were printed by `gtkdoc-check` on failure, so that they end up in build logs. This could be conditional on (e.g.) passing `--verbose` to `gtkdoc-check`.
It would make the current output from `gtkdoc-check` in the build logs more helpful. Currently it is:
```
--- command ---
DOC_MAIN_SGML_FILE='gio-docs.xml' DOC_MODULE='gio' BUILDDIR='/opt/gnome/build/glib/docs/reference/gio' /opt/gnome/install/bin/gtkdoc-check
--- stdout ---
Running suite(s): gtk-doc-gio
gio-undocumented.txt:1:E: 15 undocumented or incomplete symbols
gio-undeclared.txt:1:E: 48 undeclared symbols
50.0%: Checks 4, Failures: 2
```