4. Additional Variables

As seen in Section 1, “File Format of *.pc Files”, pkg-config allows the definition of arbitrary variables, in addition to the fixed-meaning keywords.

The use of arbitrary variables is often used to provide information decided at build-time but not necessarily consumed by the compiler and linked, for example the path in which to install plug-in objects for some software.

Defining a custom variable is the same as defining pre-defined and temporary variables, such as libdir. To query these variables within autoconf you should use the PKG_CHECK_VAR macro, provided by pkg-config.

4.1. PKG_CHECK_VAR Syntax

The syntax of this macro follows part of the conventions of Section 3, “The PKG_CHECK_MODULES Macro”, and is effectively a wrapper around AC_ARG_VAR.

PKG_CHECK_VAR(var-name, module, pkgconfig-variable, action-if-found, action-if-not-found)

The var-name parameter defines the name of the variable, to be used in configure.ac, Makefile.am and other similar files. Since this is declared through AC_ARG_VAR, defining this variable in the environment or command-line will skip the execution of pkg-config.

The module and pkgconfig-variable parameters are used to identify the file and the variable to fetch through pkg-config. You can request explicitly a minimum or maximum version number for the module, as described in Section 3.3, “Modules specification”, but unlike PKG_CHECK_MODULES you can only provide a single module to query.

While the action-if-found and action-if-not-found follow the usual semantics of autoconf macros, the latter is a catch-all for failures, and is invoked in either of the following cases: module not found, module version constraints not fulfilled, missing variable in module file.

Additionally, unlike PKG_CHECK_MODULES, this macro does not, by default, error out if the variable cannot be defined. Together with the above-noted caveat of being a no-op if the variable is already defined, it is possible to call the macro multiple times with the same var-name to find the variable in one of multiple possible modules.

4.2. A Practical Example

Example 4.3. Reading target path for plugins via PKG_CHECK_VAR

The following example assumes that there is an application called Foo that provides a plug-in interface. Details of building flags can be seen in Section 2, “Building plugins”.

dnl In configure.ac
PKG_CHECK_VAR([FOO_PLUGINDIR], [foo], [plugindir])
AC_MSG_CHECKING([foo plugins path])
AS_IF([test "x$FOO_PLUGINDIR" = "x"], [
  AC_MSG_FAILURE([Unable to identify foo plugin path.])

# In Makefile.am
fooplugindir = $(FOO_PLUGINDIR)
fooplugin_LTLIBRARIES = myplugin.la