Table of Contents
Source code packages usually need to gather specific information from the system where they are going to be built. This includes the presence and location of required programs, header files, functions, libraries, compiler features, etc. Based on check results, the package modifies program sources to ensure they will build in the actual platform or, if they fail, tell the user what to do to solve the problems. This process is called automatic configuration, and is done without user interaction, though he may provide configuration details through the command line.
In Buildtool, this process is issued by the bt_config module. See next section.
buildtool config [ -d dirname=value | --dir-dirname=value ] [--disable-name] [ -f featname=value | --feature-featname=value ] [--enable-name] [ -h | --help ] [--ignore-sw-config] [ -p value | --prefix=value ] [ -w dir | --workdir=dir ]
The bt_config module is used to automatically configure buildtoolized packages. It can be executed without extra arguments, taking defaults for most values, though it is often used with modifiers.
The following options are recognized:
-h | --help
Shows an useful help message, listing all available options plus all recognized tunable features and directories.
-d dirname=value | --dir-dirname=value
Sets the customizable directory dirname to the value given by value.
--disable-featname
Sets the customizable feature featname to no.
-f featname=value | --feature-featname=value
Sets the customizable feature featname to the value given by value.
--enable-featname
Sets the customizable feature featname to yes.
--ignore-sw-config
Do not load the system wide configuration file before configuring the package. See Chapter 6, System wide configuration.
-p value | --prefix=value
Sets the installation prefix to the value given by value.
-w dir | --workdir=dir
Sets the work directory to dir. This is used to tell the build system where to store temporary files, like objects, executables, libraries, etc. so that the source tree is not polluted in any way.
This defaults to nothing[5], meaning that all files are placed in the current directory. There is an special case, though. If you set the environment variable BT_USE_WORKDIR to yes, the work directory will be automatically set to $(pwd)/work.bt; this is very useful in case you want to build all your packages using work directories, because it can be set in bt_logic.conf.
If there are duplicated arguments in the same command line, the later take effect.
Packages can have a set of customizable directories, which tell the package where specific things get installed, and customizable features, which tell the package whether to compile some extra functionalities or not (they may have other uses, though). Several flags are used to change the values of these directories and features. Please note that directory and feature names are case insensitive.
The following command is always a good start to learn what a package provides, with respect to tunable features and directories:
$ buildtool config --help
Mosft of the directories that can be customized for a package are standard. This means that Buildtool knows them internally and are consistent across any buildtoolized package.
The first and most important is the installation prefix, which is somewhat special because is changed with its own option. It specifies which is the directory hierarchy where all files are installed. This defaults to /usr/local/. If no other directory is customized, a package will not put any file outside that hierarchy (except if there is a bug...).
Aside from the prefix, all standard directories under it are known by Buildtool and can be customized. These are:
Location of user binaries. Defaults to <prefix>/bin/.
Location of documentation files. Defaults to <prefix>/share/doc/<pkgname>-<pkgversion>.
Location of system wide configuration files. Defaults to <prefix>/etc/.
Location of example files. Defaults to <prefix>/share/examples/<pkgname>-<pkgversion>.
Location of header files. Defaults to <prefix>/include/.
Location of Info documentation. Defaults to <prefix>/info/.
Location of static and shared libraries. Defaults to <prefix>/lib/.
Location of static data used by libraries. Defaults to <prefix>/libdata/.
Location of binaries related to libraries or commands, not to be directly run by the user. Defaults to <prefix>/libexec/.
Location of man pages. Defaults to <prefix>/man/.
Location of pkgflags files. Defaults to <buildtool prefix>/share/pkgflags/.
Location of super-user binaries. Defaults to <prefix>/sbin/.
Location of shareable data. Defaults to <prefix>/share/.
Location of variable data. Defaults to <prefix>/var/.
Packages might override the values shown above by default.
Some features are internally recognized by buildtool, and therefore are common across all packages. These are:
Whether developer mode is enabled. Defaults to no. The developer mode turns on build logging, enables many compilation warnings and may also trigger other behavior as defined by the software author. If you are an end user, you should leave it disabled, as it might cause problems to you.
Whether runtime path is supported by the current system. Defaults to yes, though it is disabled if a given system or compiler does not support it.
Whether to build shared libraries or not. Defaults to auto, which means whatever the build system supports.
Whether to build static libraries or not. Defaults to auto, which means whatever the build system supports. If shared libraries are enabled, these are turned off if set to automatic.
This section shows several examples to configure a source package. It is assumed that all commands are executed from package's top directory; if not, Buildtool will simply abort. We will be using both long and short options for the samples; if multiple commands are shown, they are all equivalent.
First, a very simple but useful example. We are going to configure a package as a regular user who does not have write access to /usr/local/. Configuring with the default values will make package installation fail with access denied. So we will configure the software to use a different prefix, under our home directory:
$ buildtool config -p ~/opt $ buildtool config --prefix=~/opt
The following example shows how to change the value of a single tunable directory. We will set the prefix to the standard installation location on Linux systems, /usr/, and then change the configuration directory to the standard /etc/:
$ buildtool config -p /usr -d etc=/etc $ buildtool config --prefix=/usr --dir-etc=/etc
Now, let's enable the developer mode for a package, leaving all other settings to their defaults. It is very simple, as you can see:
$ buildtool config -f developer=yes $ buildtool config --feature-developer=yes $ buildtool config --enable-developer