In this case, make sure that the VAPI name corresponds to the pkg-config file.
If the VAPI is for an external library then make sure that the VAPI name
corresponds to the pkg-config file name.
The [`vala-extra-vapis` repository](https://github.com/nemequ/vala-extra-vapis)
is a community maintained repository of VAPIs that are not distributed.
Developers use the repository to share early work on new bindings and
improvements to existing bindings. So the VAPIs can frequently change. It is
recommended VAPIs from this repository are copied in to your project's source
files.
This also works well for starting to write new bindings before they are shared
with the `vala-extra-vapis` repository.
If no pkg-config file is provided, you must use `find_library`. Using`declare_dependency` is cleaner because it does not require passing both dependency objects to the target.
### Libraries without pkg-config files
A library that does not have a corresponding pkg-config file may mean
`dependency()` is unsuitable for finding the C and Vala interface files. In this
case it is necessary to use `find_library()`.
The first example uses Vala's POSIX binding. There is no pkg-config file because
POSIX includes the standard C library on Unix systems. All that is needed is the
VAPI file, `posix.vapi`. This is included with Vala and installed in Vala's
standard search path. Meson just needs to be told to only find the library for
the Vala compiler:
```meson
foo_lib = meson.get_compiler('c').find_library('foo') # assuming libfoo.so is installed
Some Vala bindings do not need a corresponding pkg-config file and `dependency` is unsuitable for resolving them. It's necessary to use `find_library` in this case.
If a library target is used, Meson automatically outputs the C header and the VAPI. They can be renamed by setting the `vala_header` and `vala_vapi` arguments respectively. In this case, the second and third elements of the `install_dir` array indicate the destination with `true` to indicate default directories (i.e. `include` and `share/vala/vapi`).
the C header and the VAPI. They can be renamed by setting the `vala_header` and
`vala_vapi` arguments respectively:
```meson
foo_lib = library('foo', 'foo.vala',
foo_lib = shared_library('foo', 'foo.vala',
vala_header: 'foo.h',
vala_vapi: 'foo-1.0.vapi',
dependencies: [glib_dep, gobject_dep],
install: true,
install_dir: [true, true, true])
```
In this example, the second and third elements of the `install_dir` array
indicate the destination with `true` to use default directories (i.e. `include`
and `share/vala/vapi`).
## GObject Introspection
### GObject Introspection and language bindings
A 'binding' allows another programming language to use a library written in
Vala. Because Vala uses the GObject type system as its runtime type system it is
very easy to use introspection to generate a binding. A Meson build of a Vala
library can generate the GObject introspection metadata. The metadata is then
used in separate projects with [language specific
tools](https://wiki.gnome.org/Projects/Vala/LibraryWritingBindings) to generate
a binding.
To generate GObject Introspection metadata, the `vala_gir` option has to be set with the desired name.
The main form of metadata is a GObject Introspection Repository (GIR) XML file.
GIRs are mostly used by languages that generate bindings at compile time.
Languages that generate bindings at runtime mostly use a typelib file, which is
generated from the GIR.
The fourth element in the `install_dir` array indicate where the GIR file will be installed. The `true` value tells Meson to use the default directory (i.e. `share/gir-1.0`).
Meson can generate a GIR as part of the build. For a Vala library the
`vala_gir` option has to be set for the `library`: