Table of Contents
When a developer wants to link his program against a third party library, he must know some details about it, specially all flags that need to be passed to the compiler to get a successful link. These may vary depending on the system (i.e., shared or static libraries), on the library version, etc.. There are several solutions to this problem: a configuration script, which gives the proper flags at runtime (this has been used for lots of libraries but is becoming deprecated); a pkgconfig file (mostly used by GNOME), which provides a small database of flags accessed through a common interface; and the Buildtool approach, a pkgflags file, which has the same funcionality as pkgconfig.
To write your configuration scripts, you can get library flags using any of the three approaches described above, specially using the bt_check_pkgflags function (see Section 10.7.6.4, “Package flags”) or the pkgconfig.subr module (see Section 10.8.1, “The pkgconfig module”).
Even though, when you write your own library, it is suggested that you provide pkgflags files (no extra programs needed as this is entirely handled by Buildtool itself). They store package information, like its name or its version and also all the flags needed to compile and link an application against it.
buildtool pkgflags [ -c | --cflags ] [ -h | --help ] [ -l | --libs ] pkgname,[operator,version]...
The bt_pkgflags module is used to get package flags from installed pkgflags files, which are printed to standard output. Each argument specifies a package name from which flags are requested. If the argument contains three fields instead of only one (separated by commas), the second is treated as the version operator and the third as the version number. The operator specifies the relation between the installed version and the given one, and it can be ge (greater or equal) or le (less or equal).
The following options are recognized:
-c | -cflags
Requests the list of compiler flags from the given packages.
-h | --help
Shows a short help message, listing all available options and the command syntax.
-l | --libs
Requests the list of linker flags from the given packages.
The following example could print compiler flags for the foobar library, requesting at least its 2.5 version:
$ buildtool pkgflags -c foobar,ge,2.5
Pkgflags files are very easily written and parsed. They are plain shell script files that define specific variables, which are:
The name of the package where the pkgflags file comes from.
A short comment about the pkgflags file, usually matches the package's comment.
The version of the library.
The list of compiler flags.
The list of linker flags.
Furthermore, most of the information required in these files can be filled in automatically by the configuration script, using the bt_generate_output function (see Section 10.5.1, “Generating output files”). Here is an example pkgflags file for our foobar library, containing magic strings that will be automatically completed:
BT_PREFIX="@BT_PREFIX@" BT_DIR_LIB="@BT_DIR_LIB@" BT_DIR_INCLUDE="@BT_DIR_INCLUDE@" bpf_name="@BT_PKG_NAME@" bpf_descr="@BT_PKG_COMMENT@" bpf_version="@BT_PKG_VERSION@" bpf_libs="-L${BT_DIR_LIB} -lfoobar" bpf_cflags="-I${BT_DIR_INCLUDE}"
This file could be stored as data/foobar.bpf.in inside your package. To generate the real pkgflags file, containing the right information, you should do (from the configuration script):
bt_generate_output data/foobar.bpf
And, at last, the makefile for the data directory could be:
.include "../bt_config.mk" BT_FILES_CLEANDIR+= foobar.bpf real-install: @${BT_INSTALL_DIR} ${BT_DIR_PKGFLAGS} @${BT_INSTALL_DATA} foobar.bpf ${BT_DIR_PKGFLAGS} .include <bt.prog.mk>