ERROR: 'gtkdoc-scangobj' failed with status 1

[bigon]

Hi,

When trying to build libfprint with meson 0.47.1, I get the following error:

[0/1] Running all tests. No tests defined. create-stamp debian/debhelper-build-stamp fakeroot debian/rules binary dh binary dh_testroot dh_prep dh_auto_install cd obj-x86_64-linux-gnu && DESTDIR=/<>/debian/tmp LC_ALL=C.UTF-8 ninja install [0/1] Installing files. Building documentation for libfprint ERROR: Error in gtkdoc helper script:

ERROR: 'gtkdoc-scangobj' failed with status 1 Traceback (most recent call last): File "/usr/bin/gtkdoc-scangobj", line 71, in sys.exit(scangobj.run(options)) File "/usr/share/gtk-doc/python/gtkdoc/scangobj.py", line 1230, in run for line in common.open_text(options.types): File "/usr/share/gtk-doc/python/gtkdoc/common.py", line 57, in open_text return codecs.open(filename, mode, encoding=encoding) File "/usr/lib/python2.7/codecs.py", line 898, in open file = builtin.open(filename, mode, buffering) IOError: [Errno 2] No such file or directory: '/<>/obj-x86_64-linux-gnu/doc/libfprint.types'

When removing the "--rebuild-types" option from scan_args in doc/meson.build the build succeed.

The doc/meson.build from libfprint contains:

gnome.gtkdoc('libfprint',
             main_xml: 'libfprint-docs.xml',
             src_dir: join_paths(meson.source_root(), 'libfprint'),
             dependencies: libfprint_dep,
             content_files: content_files,
             expand_content_files: expand_content_files,
             scan_args: [
               '--rebuild-types',
               '--ignore-decorators=API_EXPORTED',
               '--ignore-headers=' + ' '.join(private_headers),
             ],
             fixxref_args: [
               '--html-dir=@0@'.format(docpath),
               '--extra-dir=@0@'.format(join_paths(glib_docpath, 'glib')),
               '--extra-dir=@0@'.format(join_paths(glib_docpath, 'gobject')),
             ],
             html_assets: html_images,
             install: true)

[ignatenkobrain]

I asuume that gtk-doc has some problem with <<PKGBUILDDIR>>

[bigon]

Well, no This is replaced by sbuild (debian autobuilder thing) when printing the logs

The value of <<PKGBUILDDIR>> is /var/lib/sbuild/build/libfprint-kT2KT7/libfprint-0.8.1 or something like that

[hadess]

I asuume that gtk-doc has some problem with <>

Nope. Seems to be a problem after the Python 3.7 upgrade. This Fedora rawhide CI run for libfprint worked: https://gitlab.freedesktop.org/libfprint/libfprint/-/jobs/7618 and this one that ran today failed: https://gitlab.freedesktop.org/libfprint/libfprint/-/jobs/10021

The main difference is the Python 3.6 to 3.7 upgrade.

[hadess]

Downgrading to meson-0.46.1-2.fc29.noarch.rpm in the libfprint CI fixed/worked-around the problem. Neither 0.47.0 nor 0.47.1 managed to finish the build, with the same error.

[heftig]

It seems that gtkdoc-scan --rebuild-types will not produce a types file if it would be empty.

The libfprint build fails since 75bb6b097d07c9842c0bb9789e918051b3c2e1d4.

[ignatenkobrain]

Just for the record, libfprint fails in fedora with:

[0/1] /usr/bin/python3 /usr/bin/meson install --no-rebuild
Building documentation for libfprint
ERROR: 
Error in gtkdoc helper script:
ERROR: 'gtkdoc-scangobj' failed with status 1
Traceback (most recent call last):
  File "/usr/bin/gtkdoc-scangobj", line 71, in <module>
    sys.exit(scangobj.run(options))
  File "/usr/share/gtk-doc/python/gtkdoc/scangobj.py", line 1230, in run
    for line in common.open_text(options.types):
  File "/usr/share/gtk-doc/python/gtkdoc/common.py", line 51, in open_text
    return open(filename, mode, encoding=encoding)
FileNotFoundError: [Errno 2] No such file or directory: '/builddir/build/BUILD/libfprint-0.8.2/x86_64-redhat-linux-gnu/doc/libfprint.types'

[ignatenkobrain]

@heftig I would say that this is bug in gtk-doc. I have went and created an issue in upstream

[xclaesse]

libfprint only depends on glib, not gobject/gio, so it should just remove the --rebuild-types option. I think meson is right to expect that a .types file gets created when --rebuild-types option is passed. Could you please close this bug and report against libfprint?

[hadess]

The meson change causes a regression. If you're happy with regressions, I'm happy to fix libfprint myself.

[xclaesse]

IMO it's not a regression, it should never have been working. But I'll let @jpakkane judge on that.

[hadess]

IMO it's not a regression, it should never have been working. But I'll let @jpakkane judge on that.

If it used to work and doesn't anymore, then it's a regression. Whether we need to care about it is a completely different matter, it is matter-of-factly, a regression.

[hadess]

Worked-around upstream: https://gitlab.freedesktop.org/libfprint/libfprint/merge_requests/9

[martinpitt]

I am still running into this with meson 0.55.3 (current version in Fedora 33).

gtkdoc documentation is pretty sparse, but that's what I cobbled together from various GNOME projects and the test suite:

gnome = import('gnome')
gnome.gtkdoc('umockdev',
  main_xml: 'umockdev-docs.xml',
  src_dir: [srcdir],
  content_files: [version_xml],
  ignore_headers: ['uevent_sender.h', 'ioctl_tree.h', 'debug.h'],
  scan_args: ['--rebuild-types'],
  dependencies: [glib, gobject, declare_dependency(link_with : [umockdev_lib])],
  install: true,
)

This fails with

Traceback (most recent call last):
  File "/usr/bin/gtkdoc-scangobj", line 81, in <module>
    sys.exit(scangobj.run(options))
  File "/usr/share/gtk-doc/python/gtkdoc/scangobj.py", line 1316, in run
    for line in open(options.types, 'r', encoding='utf-8'):
FileNotFoundError: [Errno 2] No such file or directory: '/var/home/martin/upstream/umockdev/b/docs/reference/umockdev.types'

Sure, because nothing has actually built it yet. If I drop --rebuild-types, it just falls over later on, and it's also conceptually wrong -- something needs to build the *.types file.

The only way how to make it work that I found was to build with autoconf/automake first (also in a separate build dir), then deleting that build dir. This leaves a couple of files behind, but removing them one by one doesn't break it again -- this is all very mysterious.

It does not even help to disable --rebuild-types and put the .types file into the git source tree.

So this will require some further weird debugging what on earth an automake build does to the build tree to fix meson's gtk-doc build.

[martinpitt]

This drives me nuts.. I can get a working documentation build with the above with

cp b/umockdev.h src/ && cp b/libumockdev.so.0.3.0.p/src/umockdev.c

after meson compile and before meson install. That correctly builds ./b/docs/reference/umockdev.types, and the HTML files are correct and complete. So apparently the gtk-doc scanner doesn't look into the build dir. I originally specified src_dir: [srcdir] (see previous comment), so I thought "ok, let's add the build dir" with

src_dir: [srcdir, meson.current_build_dir()],

or even just

 src_dir: [meson.current_build_dir()]

and

cp b/libumockdev.so.0.3.0.p/src/umockdev.c b/

so that at least 50% of the hack goes away, and I don't need to clobber the original source dir. But then it doesn't build the *.types file again. meson install also doesn't say what it's doing (#5631), so that it's hard to see command lines and drill down into the gtk-doc commands, to see where stuff goes wrong.

... aside from the fact that the gtk-doc build ought to happen during build already, not just install.

Does anyone know an example where a vala library gets gtk-doc built with meson?

[martinpitt]

src_dir: [srcdir, meson.current_build_dir()]

That was wrong, as that happened in a docs/reference/ subdir. I needed to use

src_dir: [meson.build_root(), meson.build_root() / 'libumockdev.so.@0@.p/src'.format(lib_version)],

which then finally works. The second is an utter hack of course, as it makes assumptions about internal implementation details of meson where it puts the generated umockdev.c from the umockdev.vala source -- but I haven't found a way to do that cleanly.

So the umockdev meson branch has this working now, in case anyone else needs this as well.

[eli-schwartz]

meson install also doesn't say what it's doing (#5631), so that it's hard to see command lines and drill down into the gtk-doc commands, to see where stuff goes wrong.

... aside from the fact that the gtk-doc build ought to happen during build already, not just install.

Nothing to do with meson install.

gtkdoc in meson is implemented by the gnome module, which internally adds a meson.add_install_script() that builds & installs the docs (yes, building during install), which should actually be printed but in actuality it is just running the mesonbuild/scripts/gtkdochelper.py wrapper

Generally this is an issue because of things like #5793

[eli-schwartz]

I've previously helped debug issues where the build-on-install thing was badly erroring out, because there was stuff not actually being done at the right time which gtkdoc depended on. This seems similar to your *.types problem.

There should be a .PHONY target created called "umockdev-doc" which will build the docs in tree, and should work. meson install will rebuild them again unnecessarily, but as long as they are built once I hope it should successfully build twice... does this work for you?