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 --helpMosft 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:
BINLocation of user binaries. Defaults to
<prefix>/bin/.
DOCLocation of documentation files.
Defaults to <prefix>/share/doc/<pkgname>-<pkgversion>.
ETCLocation of system wide configuration files.
Defaults to <prefix>/etc/.
EXAMPLESLocation of example files. Defaults to
<prefix>/share/examples/<pkgname>-<pkgversion>.
INCLUDELocation of header files. Defaults to
<prefix>/include/.
INFOLocation of Info documentation. Defaults to
<prefix>/info/.
LIBLocation of static and shared libraries.
Defaults to <prefix>/lib/.
LIBDATALocation of static data used by libraries.
Defaults to <prefix>/libdata/.
LIBEXECLocation of binaries related to libraries or
commands, not to be directly run by the user. Defaults to
<prefix>/libexec/.
MANLocation of man pages. Defaults to
<prefix>/man/.
PKGFLAGSLocation of pkgflags files. Defaults to
<buildtool
prefix>/share/pkgflags/.
SBINLocation of super-user binaries. Defaults to
<prefix>/sbin/.
SHARELocation of shareable data. Defaults to
<prefix>/share/.
VARLocation 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:
DEVELOPERWhether 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.
RPATHWhether 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.
SHAREDWhether to build shared libraries or not.
Defaults to auto, which means whatever the build
system supports.
STATICWhether 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