This will allow using gtk-doc as a subproject instead of having to
install it on the system. It also has the side effect of failing at
configuration time with a proper message if gtkdoc is not installed,
instead of failing at build time with a python backtrace.
gtk-doc for autotools has the concept of module version, that is used to define
the module install path and the devhelp2 basename.
Add a `module_version` parameter to gnome.gtkdoc to replicate the same behavior.
Updated the test checking that the install_dir is properly computed (if not
passed), and that the .devhelp2 file has proper name.
https://gitlab.gnome.org/GNOME/gtk-doc/blob/GTK_DOC_1_29/buildsystems/autotools/gtk-doc.make#L269
The code was adding the library paths to LD_LIBRARY_PATH, but that
doesn't work on Windows where they need to be added to PATH instead.
Move the environ handling into gtkdoc_run_check() and add paths to PATH
instead of LD_LIBRARY_PATH when on Windows.
This fixes the gtk-doc build for glib on Windows
(in case glib isn't installed already)
gtkdoc-scangobj has a --run argument that specifies a wrapper to be used when
executing the GObject scanner. Typically this can be libtool but it is also
useful in cross-compilation environments.
This patch adds support for this argument to the gtkdochelper so that tools
using the helper can pass --run if required.
If we pass a source files() object, we will look for it in the build
directory, which is wrong. If we pass a build files() object (from
configure_file()), we will find it in the build directory, and then
try to copy it on top of itself in gtkdochelper.py getting a
SameFileError.
Add a test for it, and also properly iterate custom target outputs
when adding to content files.
gnome.gtkdoc uses -Wl,-rpath to ensure the scanner executable built by
gtkdoc-scangobj will load shared libraries from the correct directories.
However, FreeBSD configures its linker to use --enable-new-dtags by
default, which converts RPATH to RUNPATH. If users have LD_LIBRARY_PATH
environment variable set, RUNPATH will be overrided by LD_LIBRARY_PATH
and libraries will be loaded from wrong directories, causing undefined
symbol error when running the executable.
In order to solve the problem, we have to prepend directories specified
with -Wl,-rpath to LD_LIBRARY_PATH to avoid relying on the deprecated
RPATH attribute.
There are cases where we need to specify arguments to gtkdoc-mkdb, like
telling it to scan extensions that are not '.h' and '.c'. Let's add a
new named argument to gnome.gtkdoc(), as well as the plumbing needed for
the gtk-doc helper script.
'gtkdoc-scangobj' script was recently ported to Python (it was Perl), and it now requires providing '--type' option to specify the name of the file to store the types in. Without this option, 'gtkdockelper' will exit with error status 2 and will throw a message "gtkdoc-scangobj: error: unrecognized arguments: <typefile>"
Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
Using 'mesonbuild' as the module can cause it to use the
system-installed module and can also break if we rename the directory,
so avoid that by always using relative imports.
Not all headers are public, or contain public types. GTK-Doc allows
adding headers to be ignored during the "scan" phase, by passing the
`--ignore-headers` command line argument to gtkdoc-scan.
Currently, you can do something like:
ignored_headers = [ 'foo-private.h', 'bar-private.h', ]
gnome.gtkdoc(...
scan_args: [
'--ignore-headers=' + ' '.join(ignored_headers),
],
...)
But it does not guarantee escaping rules and it's definitely not nice.
We can add a simpler version of that mechanism through a new positional
argument, `ignore_headers`, which behaves like `content_files` or
`html_assets`, and takes an array of header files to ignore:
gnome.gtkdoc(...
ignore_headers: ignored_headers,
...)
If a `<modulename>-overrides.txt` file exists in the docs directory it
means it's intended to be used in place of the one gtk-doc generates.
GLib and GTK+, for instance, ship with one because some of the types
they provide — like the thread primitives, or the platform macros —
contain architecture-dependent fields that should not be accessed
directly.
This commit should close the last bit of issue #550.
Allowing the object tree to be generated.
We need to add options to allow copying the ncesseary sources and
assets so the HTML generator can work with them (everything is
relative so we need to copy them in the build directory).
Until now the documentation was not generated from the user provided
main sgml file but it was using a generated one, which lead to a broken
documentation. Starting using it revealed the other bugs fixed in that
commit.
The extra arguments are typically used to specified the location of
installed API references that gtk-doc can use to create cross links
for symbols.
Fixes#555