Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERROR: 'gtkdoc-scangobj' failed with status 1 #3892

Open
bigon opened this issue Jul 16, 2018 · 17 comments
Open

ERROR: 'gtkdoc-scangobj' failed with status 1 #3892

bigon opened this issue Jul 16, 2018 · 17 comments

Comments

@bigon
Copy link

@bigon bigon commented Jul 16, 2018

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
Copy link
Member

@ignatenkobrain ignatenkobrain commented Jul 16, 2018

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

@bigon
Copy link
Author

@bigon bigon commented Jul 16, 2018

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
Copy link

@hadess hadess commented Jul 16, 2018

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
Copy link

@hadess hadess commented Jul 17, 2018

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.

fdo-mirror pushed a commit to freedesktop/libfprint that referenced this issue Jul 17, 2018
It failed to finish the build otherwise:
mesonbuild/meson#3892
@heftig
Copy link
Contributor

@heftig heftig commented Jul 17, 2018

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

The libfprint build fails since 75bb6b0.

@ignatenkobrain
Copy link
Member

@ignatenkobrain ignatenkobrain commented Jul 18, 2018

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
Copy link
Member

@ignatenkobrain ignatenkobrain commented Jul 18, 2018

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

@xclaesse
Copy link
Member

@xclaesse xclaesse commented Jul 18, 2018

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
Copy link

@hadess hadess commented Jul 18, 2018

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

@xclaesse
Copy link
Member

@xclaesse xclaesse commented Jul 18, 2018

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

@hadess
Copy link

@hadess hadess commented Jul 18, 2018

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.

fdo-mirror pushed a commit to freedesktop/libfprint that referenced this issue Jul 20, 2018
The gtk-doc meson helper regressed in that it didn't expect the
libfprint.types file to not exist, as earlier versions did. Remove
the --rebuild-types call so that it is not generated, and meson carries
on compiling the rest of the library.

See https://gitlab.gnome.org/GNOME/gtk-doc/issues/48
See mesonbuild/meson#3892
See https://bugzilla.redhat.com/show_bug.cgi?id=1604585
@hadess
Copy link

@hadess hadess commented Jul 20, 2018

@martinpitt
Copy link

@martinpitt martinpitt commented Nov 7, 2020

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
Copy link

@martinpitt martinpitt commented Nov 14, 2020

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
Copy link

@martinpitt martinpitt commented Nov 14, 2020

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.

hadess added a commit to hadess/umockdev that referenced this issue Aug 25, 2021
umockdev doesn't export any GObject object types, so gtk-doc should not
be trying to create an empty types file, or including an object class
tree in its documentation.

See https://gitlab.gnome.org/GNOME/gtk-doc/issues/48
See mesonbuild/meson#3892
See https://bugzilla.redhat.com/show_bug.cgi?id=1604585
martinpitt added a commit to martinpitt/umockdev that referenced this issue Aug 25, 2021
umockdev doesn't export any GObject object types, so gtk-doc should not
be trying to create an empty types file, or including an object class
tree in its documentation.

See https://gitlab.gnome.org/GNOME/gtk-doc/issues/48
See mesonbuild/meson#3892
See https://bugzilla.redhat.com/show_bug.cgi?id=1604585
hadess added a commit to hadess/umockdev that referenced this issue Aug 26, 2021
meson doesn't seem to have a way to tell gtk-doc where the .c files to
extract the type functions from would be when they're generated, like
they are for Vala sources.

Work around this by providing a static .types file.

See mesonbuild/meson#3892
benzea added a commit to martinpitt/umockdev that referenced this issue Aug 27, 2021
meson doesn't seem to have a way to tell gtk-doc where the .c files to
extract the type functions from would be when they're generated, like
they are for Vala sources.

Work around this by providing a static .types file.

See mesonbuild/meson#3892
@eli-schwartz
Copy link
Member

@eli-schwartz eli-schwartz commented Aug 31, 2021

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
Copy link
Member

@eli-schwartz eli-schwartz commented Aug 31, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants