meson: Vala pkg-config dependency checks don't look for vapi files

Currently, our vala pkg-config support works like this:

We use a simple pkg-config dependency check: dependency('foo-2.4')
While compiling vala files for a target, we unconditionally add --pkg=foo-2.4 for each pkg-config dependency listed for that target

This is correct about 80% of the time. It breaks in the following cases:

a) There’s no foo-2.4.vapi file corresponding to the foo-2.4.pc file. This can happen because of one of two reasons:

No .vapi file is shipped with any vala package for that library (e.g.: uuid.pc)
The correct vala development package hasn’t been installed (e.g.: libosinfo-vala on Fedora)

b) We don’t actually want to use that dependency in the Vala sources. It is only used in the C sources. This is harmless if a vapi file for that dep actually exists, but if it doesn’t it will cause an unnecessary error. c) The foo-2.4.vapi file corresponding to the foo-2.4.pc file is shipped with the source tree. (e.g. govirt-1.0.vapi is shipped with the Boxes source tree. d) No foo-2.4.vapi file is needed because the information contained in the vapi file is embedded in the source (e.g. Boxes does this for libuuid).

I haven’t found any cases where the vapi file has a different basename than the pc file.

About this issue

Original URL
State: open
Created 8 years ago
Comments: 19 (19 by maintainers)

Most upvoted comments

I agree that we need a way to add a dependency to a target that does not imply a --pkg flag. I would be more in favor of a language-specific option like has_vapi:

uuid_dep = dependency('uuid', has_vapi: false)

For private bindings, it’s effectively the best approach to add them directly to the sources, but for public ones, it’s better to keep the in standard/extended paths as you would expect them to be. We could use the has_vapi flag with a private binding shipped with the sources.

This is the error you get, which is not that cryptic:

error: Package `uuid' not found in specified Vala API directories or GObject-Introspection GIR directories
Compilation failed: 1 error(s), 0 warning(s)

Ideally we would be searching for all the VAPIs at configure-time, but that’s a non-trivial task. The search path depends on the API version of the compiler, the *.deps files found alongside and GIR packages are also supported. I think it’s best to process them like we do for headers: use inclusion paths and explicit files directly on the target.

arteymix on Dec 26, 2016

No, find_library doesn’t use any additional search paths from add_project_arguments. However, find_library has a parameter called dirs that can be used to add additional search paths.

gitg uses this feature to include custom VAPI packages.

inigomartinez on Jan 2, 2019

@inigomartinez:

gitg provides the vapi file which is called gdesktop-enums-3.0.vapi and a metadata file called GDesktopEnums-3.0.metadata. These names follow the name used for the GIR file GDesktopEnums-3.0.gir, so they make sense. However the pc file is called gsettings-desktop-schemas.pc, which causes an error when the vapi file is not found

The .metadata file has to follow the name of the GIR, but the VAPI generated can be called whatever you like. In this case it should be gsettings-desktop-schemas.vapi. Here is an example using vapigen for libvips:

vapigen \
         --library vips \
         --pkg gobject-2.0 \
         --pkg glib-2.0 \
         --pkg gmodule-2.0 \
         --metadatadir . \
         Vips-8.0-custom.vala \
         /usr/share/gir-1.0/Vips-8.0.gir

This produces a VAPI called vips.vapi. vapigen uses the library name passed to it and adds the .vapi extension. Using gnome.generate_vapi() in a meson.build file would be something like (untested):

gnome.generate_vapi( 'vips',
  packages: ['gobject-2.0', 'glib-2.0', 'gmodule-2.0'],
  sources: ['Vips-8.0', 'Vips-8.0-custom.vala']
  )

So you simply need to change gdesktop-enums-3.0.vapi to gsettings-desktop-schemas.vapi in your build.

I would question though why gitg is carrying several third party VAPIs: https://git.gnome.org/browse/gitg/tree/vapi I haven’t checked all, but bindings like libsoup-2.4 are carried upstream and are likely to be removed from the Vala distribution itself shortly - see https://bugzilla.gnome.org/show_bug.cgi?id=773197 Having these VAPIs also distributed with gitg doesn’t make sense.

So for gdesktop-enums-3.0.vapi you should ideally generate this as part of the gsettings-desktop-schemas project and rename the VAPI to gsettings-desktop-schemas.vapi. So it is then distributed with the development files.

Your example is more to do with how the Vala community manage distribution of bindings than it is to do with Meson working around any problems. If you can’t get this upstream then gnome.generate_vapi should be enough to generate a correctly named VAPI.

astavale on Oct 11, 2017