mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-07-25 19:37:52 +02:00
.gitlab-ci
.reuse
LICENSES
docs
reference
gio
girepository
glib
gmodule
gmodule.toml.in
meson.build
modules.md
gobject
AUTHORS
COPYING
NEWS
meson.build
urlmap.js
CODEOWNERS
backports.md
issue-and-merge-request-management.md
macros.md
meson-version.md
rationales.md
releasing.md
roadmap.md
supported-platforms.md
testing.md
toolchain-requirements.md
win32-build.md
fuzzing
gio
girepository
glib
gmodule
gobject
gthread
m4macros
po
subprojects
tests
tools
.clang-format
.dir-locals.el
.editorconfig
.gitignore
.gitlab-ci.yml
.gitmodules
.lcovrc
CODE_OF_CONDUCT.md
CONTRIBUTING.md
COPYING
INSTALL.md
NEWS
README.md
SECURITY.md
glib.doap
meson.build
meson.options
548ec9f186
The `gi-docgen` tool is not designed to be used like that. In
particular, when nesting documentation directories, the generated
`*.devhelp2` files (needed by Devhelp to show the documentation) are
nested one directory level too deep for Devhelp to find them, and hence
are useless, and the documentation doesn’t show up in this common
documentation viewer.
So, change the installed documentation directory hierarchy:
* `${PREFIX}/share/doc/glib-2.0/gio` → `${PREFIX}/share/doc/gio-2.0`
* `${PREFIX}/share/doc/glib-2.0/glib-unix` →
`${PREFIX}/share/doc/glib-unix-2.0`
* `${PREFIX}/share/doc/glib-2.0/gobject` →
`${PREFIX}/share/doc/gobject-2.0`
* etc.
* `${PREFIX}/share/doc/glib-2.0/glib` → `${PREFIX}/share/doc/glib-2.0`
This is going to seem like pointless churn (the contents of the
documentation have not changed), and packagers may mourn the split of
content in `/usr/share/doc` from `/usr/share/doc/${package_name}` to
`/usr/share/doc/${pkg_config_id}` instead, but that seems to be the best
approach to fix this issue in GLib. gi-docgen’s behaviour does feel
fairly consistent and correct with the rest of how it works (single
output directory).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3287