This is buildtool.info, produced by makeinfo version 4.0 from
buildtool.texi.

INFO-DIR-SECTION Programming & development tools
START-INFO-DIR-ENTRY
* Buildtool: (buildtool).       Build infrastructure for source packages.
END-INFO-DIR-ENTRY


File: buildtool.info,  Node: Top,  Next: Introduction,  Up: (dir)

Buildtool's Manual
******************

   Buildtool is a free, portable, BSD-style build infrastructure for
source packages. This manual describes how to use Buildtool as an end
user and as a developer; it corresponds to Buildtool 0.10.

   Copyright (C) 2002, 2003, Julio Merino

* Menu:

* Introduction::         Buildtool's purpose and general concepts.
* License::              BSD license terms.
* Modules::              Description of available modules.
* Comparisons::          Buildtool vs. other tools.
* Tutorial::             Step by step tutorial, for the end user.
* Site defaults::        How to provide local site defaults.
* Package structure::    How a package is structured.
* Definitions::          Generic package details.
* Configuration::        Writing auto-configuration scripts.
* Makefiles::            The BSD-style Makefile infrastructure.
* Installation::         Installing files from Makefiles.
* Documents::            Adding build documentation.
* Verification::         Checking that your package is ok.
* Distfiles::            Easy creation of distribution files.
* Function index::       Functions provided by bt_config.
* Variable index::       Variables used in definitions and bt_make.


File: buildtool.info,  Node: Introduction,  Next: License,  Prev: Top,  Up: Top

Introduction
************

   Buildtool is an integrated set of utilities designed to simplify the
build system used in source code packages. The build system is a
process formed by these three steps: configure the sources, build them
and install the results. Buildtool provides the necessary tools to
accomplish all of these. Even more, it also contains convenience tools
to make your package more user-friendly.

   If you have ever used some of the GNU build system utilities such as
Autoconf, Automake and/or Libtool, you will see that Buildtool provides
most of their functionality. In fact, it is an implementation of the
same concepts, although the way to accomplish them is quite different.
*Note Comparisons::.

   Here are some terms that you should get familiar with before
continuing:

`Buildtool-ized package'
     A source package that uses Buildtool as its build system. The
     package cannot be built without Buildtool.

`Module'
     The same as a "tool", used in previous paragraphs.

   Buildtool imposes some properties to buildtool-ized packages by
desing; therefore all of them share some common topics:

   * Ability to autoconfigure theirselves _without_ manual user
     intervention. This is known as the _configuration step_.

   * Consistant targets to build, install and clean the sources (aside
     from other no-so-popular allowed targets).

   * Simple and clean (but powerful) Makefiles spread in subdirectories
     which do specific tasks.


File: buildtool.info,  Node: License,  Next: Modules,  Prev: Introduction,  Up: Top

BSD license terms
*****************

   Buildtool is licensed under the terms of the BSD license. The bt_make
module has been taken from The NetBSD Project, so it originally belongs
to the _NetBSD Foundation, Inc._ and/or to the _University of
California_ (depending on the source file).

   Below is the copyright notice and license details:

   Copyright (c) 2002, 2003, Julio Merino

   Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

  1. Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.

  2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the
     distribution.

  3. Neither the name of the author nor the names of contributors may be
     used to endorse or promote products derived from this software
     without specific prior written permission.

   THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


File: buildtool.info,  Node: Modules,  Next: Comparisons,  Prev: License,  Up: Top

Description of available modules
********************************

   Buildtool is modular: it is easily extensible and scalable. Each
functionality is implemented in a standalone module (its name is
prefixed by the `bt_' string). All modules are called through a
wrapper, which takes care to run the selected module with the right
arguments.

   Available modules include:

`bt_config'
     Automatically configure the source code, without user interaction.
     This module determines specific system features that are relevant
     to the current program.

`bt_dist'
     Construct distribution files of your package. These include source
     compressed formats, like `.tar.gz' or `.tar.bz2'. In a future,
     this may also implement binary packages.

`bt_doc'
     Shows package-related documentation (i.e. the license, the
     `README', etc). to the user in a consistant way.

`bt_lint'
     A package verifier. This module checks for several details of your
     package to see if it is correct.

`bt_logic'
     Implements all required logic to get Buildtool's functionality
     working.  More specifically, it parses all calls to the compiler
     and linker, sorts arguments, rewrites them depending on the
     platform and at last calls the altered command.  Furthermore it
     provides dependancy generation and installation of stuff.

`bt_make'
     A make program (pmake) plus a Makefile infrastructure. These
     Makefiles know how to build and install any kind of file,
     providing standard targets automatically.


File: buildtool.info,  Node: Comparisons,  Next: Tutorial,  Prev: Modules,  Up: Top

Buildtool vs. other tools
*************************

   As we already said in the Introduction *Note Introduction::,
Buildtool is inspired in the ideas of the most common GNU build tools:
Autoconf, Automake and Libtool (called the _Auto tools_). The following
is list of differences between the two set of tools:

   * Buildtool is BSD licensed, while Auto tools are GPL licensed.

   * Auto tools are independant; they try to work together, but it may
     get tricky. Instead, Buildtool is a well integrated set of tools
     (you will not want to use a single tool without using the other).

   * Auto tools cause a lot of size overhead in your packages,
     generating huge files to work. For example, Autoconf creates a
     `configure' script, while Automake generates lots of real
     Makefiles. These files can become extremely big (and remember, you
     have to download them over and over again, with each package!).
     Around 10% of package's size is destinated to these tools.
     Buildtool does _not_ do this: package configuration scripts and
     Makefiles are small, very small, and they do not need any kind of
     pre-processing.

   * Related with the above point, the pre-generation of files done by
     Auto tool has an advantadge: the end-user is not required to have
     the tools installed in his system (if he does not want to tweak the
     package)(1). Buildtool, instead, must be installed in every system
     to build a single buildtool-ized package. You may think that this
     is a disadvantadge, but not really. When you build programs, you
     usually must have several tools, like a make, a C compiler, other
     third-party tools (like Perl), etc. Do you really mind installing
     just another, little one? The clear answer is: _no_.

   * Auto tools pollute the environment, by defining lots of variables.
     These variables may collide with your own ones and cause hard to
     track side effects. Buildtool solves this problem by defining all
     variables and macros in their own namespace; all private variables
     are also scoped.

   ---------- Footnotes ----------

   (1) BSD package maintainers (pkgsrc or ports) know how evil this is.


File: buildtool.info,  Node: Tutorial,  Next: Site defaults,  Prev: Comparisons,  Up: Top

Step by step tutorial
*********************

   This chapter contains a tutorial destinated to the end user who has
just downloaded a buildtool-ized package and wants to do "something"
useful with it. We will assume that the package is called `tutorial',
and that the file you got is named `tutorial-1.0.tar.gz'. If you want
to see a real package in action you can check `testsuite' directory
contained in Buildtool's distribution file.

   Let's start.

* Menu:

* Unpacking::           Unpacking a source distribution file.
* Getting informed::    Getting a general overview of the package.
* Configuring::         How to auto-configure the package.
* Making::              How to build, install, deinstall and clean.


File: buildtool.info,  Node: Unpacking,  Next: Getting informed,  Prev: Tutorial,  Up: Tutorial

Unpacking a distfile
====================

   The first step after downloading a source package is to unpack it,
obviously. As it is in the common `tar.gz' format(1) we will do
something like:

     $ tar xzf tutorial-1.0.tar.gz
     $ cd tutorial-1.0

   Almost all buildtool-ized packages will unpack in their own
subdirectory, with the same name as the distribution file, except for
the extension.

   ---------- Footnotes ----------

   (1) If you are not sure what kind of file you have downloaded, use
the standard `file' command to guess it.


File: buildtool.info,  Node: Getting informed,  Next: Configuring,  Prev: Unpacking,  Up: Tutorial

Getting informed
================

   First thing to verify after extraction: is the package
buildtool-ized?  Well, there are two ways to know this:

   * A `README.bt' file exists in the top directory. If this is the
     situation, take two minutes to read it. This file may not be
     present, as it is optional.

   * A `buildtool.d' subdirectory. This is a _must_ for all
     buildtool-ized packages.

   After this, we will launch the integrated Buildtool Documentation
Reader, bt_doc, using the command:

     $ buildtool doc

   A menu will appear with several options, containing pointers to some
documents (related to the package) of interest. You are encouraged to
read them all before continuing, as they may contain important
information.

   As a note, you can set the default pager used to read documentation
before starting bt_doc. Simply set the environmental variable
`BT_PAGER' or `PAGER' to the name of you preferred one.


File: buildtool.info,  Node: Configuring,  Next: Making,  Prev: Getting informed,  Up: Tutorial

Configuring the sources
=======================

   This is probably the most complex step, as you may want to tune
package directories and features, or may be required to install
dependancies if checks fail.

   The simplest form to configure the package is like this:

     $ buildtool config

   This is fine in some cases, but you will almost always want to
configure some details of the package by hand. The most common change
is where all things get installed, i.e. the prefix. The _prefix_
defaults to `/usr/local' in most packages, but you may want to set it
to `/opt', for example. The process is very simple:

     $ buildtool config -p /opt

   Simple, eh? But wait, that's not all!

   We can tune things a bit more, specially selecting customizable
features and directories. Start by getting a general idea of what can
be tuned (the following example contains command outputs, too):

     $ buildtool config -H dirs
     bt_config: loading system-wide configuration
     Available directories:
         BIN, defaults to `/usr/local/bin'.
         ETC, defaults to `/usr/local/etc'.
         INCLUDE, defaults to `/usr/local/include'.
         INFO, defaults to `/usr/local/info'.
         LIB, defaults to `/usr/local/lib'.
         LIBDATA, defaults to `/usr/local/libdata'.
         LIBEXEC, defaults to `/usr/local/libexec'.
         MAN, defaults to `/usr/local/man'.
         SBIN, defaults to `/usr/local/sbin'.
         SHARE, defaults to `/usr/local/share'.
         VAR, defaults to `/usr/local/var'.
     
     $ buildtool config -H features
     bt_config: loading system-wide configuration
     Available features:
         OPENSSL, defaults to `no'.

   Well, we have got a full list of directories and features ready to be
configured. This would launch the configuration modifying some of the
defaults:

     $ buildtool config -p /opt -f OPENSSL=yes -d BIN=$HOME/bin


File: buildtool.info,  Node: Making,  Prev: Configuring,  Up: Tutorial

Making targets
==============

   Now that the configuration is complete we can start building the
package. If it was designed with portability in mind, it should compile
cleanly; if not, you will want to contact the author to let him know
any issues you may find.

   To launch the build process the command is simple, very simple:

     $ buildtool make

   This will take a while, depending on the package. Have a coffee.
Well, it has finished, so install the results:

     $ buildtool make install

   The installation will place all files in the directories you
customized, so it will not touch any other "unknown" directory.  When
the installation finishes, launch the installed program to see if it
works properly.

   But what? Don't you like what you just installed? So deinstall it:

     $ buildtool make deinstall

   This target will try to remove all installed files, although some
empty directories may remain. Remove them by hand if they disturb you.

   And at last, you can clean up the sources if you want to gain some
space. You have two different possibilities:

     $ buildtool make clean
     $ buildtool make cleandir

   Note that `cleandir' implies `clean', so if you use the second call,
the first is redundant.


File: buildtool.info,  Node: Site defaults,  Next: Package structure,  Prev: Tutorial,  Up: Top

Site defaults
*************

   The system administrator can (and is encouraged to) provide site
specific defaults to Buildtool. For example, he can setup the default
`BT_PREFIX' (where things are installed), or preconfigure the C
compiler (so it is not searched every time a user needs it).

   Defaults are provided on a per-module basis. This system will look
inside XXX: `@DIR_CONF@' for configuration files. Each configuration
file is named `module_name.conf', and is placed inside the
configuration directory.

   Supported files include:

`bt_config.conf'
     This is the most useful. You can setup location of binaries,
     installation directories... (XXX: headers, libraries, etc. when
     supported). This is a shell script.

`bt_make.conf'
     Usually you will not want to modify this, because bt_make inherits
     most of the variables defined by bt_config. Although, you may want
     to add here specific things, if you know what you are doing. This
     is a Makefile.


File: buildtool.info,  Node: Package structure,  Next: Definitions,  Prev: Site defaults,  Up: Top

Package structure
*****************

   Buildtool-ized packages share a common structure, spread in several
subdirectories. There are also several recommendations of interest
(like which files should be present or not).

   If you are creating a new package, you should take care to follow
these guidelines; you are free not to follow them if you do not want.
The bt_dist module will help you to check if you have applied the rules
properly.

* Menu:

* Hierarchy::        How to organize package files.
* Control files::    Files allowed in the control directory.
* Top files::        Recommended documents in the top directory.
* Templates::        Using templates to create initial files.


File: buildtool.info,  Node: Hierarchy,  Next: Control files,  Prev: Package structure,  Up: Package structure

Directory hierarchy
===================

   To make your packages simple and well structured, here are some
recommendations about how to organize your directories. Note that the
only one required is `buildtool.d'.

`Top directory'
     Holds all sub-directories of the package. No source files should be
     placed here. The only thing you should store here is build-related
     documentation, like a `README' document, a `CHANGES' history, etc.
     These documents are usually recognized by the bt_doc module.

`buildtool.d'
     The _control directory_. It holds specific Buildtool files, needed
     by all modules to work.

`bin'
     All programs, each one in is own subdirectory inside this one, like
     `bin/myprog'. This directory can also be named `src', `progs',
     `sbin'... Use your best judgement to decide which name to use.
     Note that specific manpages to each program go here too.

`dist'
     Third-party imported programs, that you do not directly develop but
     want to distribute them together with your package (be careful with
     licenses).

`doc'
     Generic documenation, for example TeXinfo files or Docbook
     documents. You should organize each "book" in its own subdirectory
     inside this one, like `doc/foobook'.

`lib'
     Libraries provided by the package (even if they are only
     internal). Each library should be in its own subdirectory inside
     this one, like `lib/libfoo'. Note that specific manpages to each
     library go here too.


File: buildtool.info,  Node: Control files,  Next: Top files,  Prev: Hierarchy,  Up: Package structure

Control files
=============

   The following table contains an exhaustive list of files allowed in
the `buildtool.d' control directory. Some files may be specific to a
single module, although others will be required by all of them.

`config'
     The configuration script, which does system specific checks and
     source code autoconfiguration; all the logic is included here.

`config_init'
     Configuration initialization, used to extend bt_config argument
     parsing. This file is used to define customizable directories or
     features, for example.

`defs'
     Important variables (definitions) that affect the package, like its
     name, its version, etc.

`docs'
     A list of build related documentation that is available to the user
     through the bt_doc module.

   Aside from this files, there is another kind of important files:
Makefiles. These are not placed in the control directory because they
depend on the current directory. Therefore, each subdirectory in your
package will contain a `Makefile.bt' that manages it. Keep in mind that
each Makefile does exactly _one_ thing, so if you need to build several
programs, you need to put them in several subdirectories.


File: buildtool.info,  Node: Top files,  Next: Templates,  Prev: Control files,  Up: Package structure

Recommended documents
=====================

   The top directory of a package is reserved to hold build and package
related documentation. You can place as many documents as you want
using any name you can think. Although, you should maintain some
consistency with other packages developed by other people. The
following table contains a list of _recommended_ documents; you may not
want to include them though; or you may want to use different names to
support other standards (like The GNU Standards).

`CHANGES'
     A list of the most important changes between different versions.
     You should not include here a very specific list of details, as
     this is kept by Configuration Management systems, like CVS, if you
     are using any of them.

`PEOPLE'
     Authors, contributors, or any other kind of people related to your
     package. This file overrides `AUTHORS' and `THANKS' present in
     most package. Why keep two different files that contain the same
     kind of information?

`README'
     Generic documentation about your package that is of interest to end
     users building and/or installing it.

`README.bt'
     Automatically provided by Buildtool, this file tells the user that
     the package is Buildtool-ized and how to get more information. You
     should not modify this document, as it should remain the same in
     all packages that include it.


File: buildtool.info,  Node: Templates,  Prev: Top files,  Up: Package structure

Using templates
===============

   Buildtool provides an easy way to buildtool-ize a new package. Using
the `maketemplate' target, Buildtool will create a sample directory
structure and will copy template files to these new directories ready
for edition. Suppose you are creating a new package called `mypackage',
you can issue:

     $ mkdir mypackage
     $ cd mypackage
     $ buildtool maketemplate

   Template files are usually well-documented, so take a look at them
now and get used to the generated structure.


File: buildtool.info,  Node: Definitions,  Next: Configuration,  Prev: Package structure,  Up: Top

Generic package definitions
***************************

   The `defs' control file is read by most of Buildtool modules; it
contains generic information about the current package, like its name,
its version, etc. It may also set default values for customizable
directories, *Note Directories::, and customizable features *Note
Features::.

   The contents of this file are simple bourne-shell variable
assignments.  These variables are recognized:

BT_PKG_COMMENT
     A one-line description of package's purpose. Should start in
     uppercase and not contain an ending dot.

BT_PKG_DISTFMTS
     A list of default formats of distribution files. Defaults to
     `tar.gz'.

BT_PKG_HOMEPAGE
     The homepage of the package. Must contain a valid URL.

BT_PKG_LICENSE
     The name of the license which the package is based on, in lowercase
     and without spaces.

BT_PKG_MAINTAINER
     The email of the responsible party. This can be a single person or
     a mailing list where bugs can be reported or questions asked.

BT_PKG_NAME
     The package name, which matches the distribution file name except
     the version. Usually in lowercase, without spaces. Examples:
     `myprog', `myprog-plugin'.

BT_PKG_VERSION
     The package version string, free form. Examples: `1.0',
     `20020922', `2.0pre1', etc.

BT_PREFIX
     Default installation prefix. If not specified, it takes the default
     value `/usr/local' if no third-party modules are used.

BT_REQUIRE
     The minimun version of Buildtool we need to build the package.


File: buildtool.info,  Node: Configuration,  Next: Makefiles,  Prev: Definitions,  Up: Top

Source code auto-configuration
******************************

   We live in a world governed by lots of different operating systems
and machine types. Each system has its own features (and/or bugs) which
can make your program unportable. Even if you have coded it in a
portable way, you will usually need to check for the presence of a
compiler, specific libraries, the size of variable types, architecture,
etc. All this work is done in a step called _source code
auto-configuration_(1).

   The bt_config module provides enough functionality to accomplish this
task in a simple way. The module is a set of bourne-shell functions
that do the most common checks. The logic of the process is the
following: you check for all the required features at the beginning
and, at last, you create (automatically) a serie of configuration files
used by other modules or sources to know what was detected.

   Scripts are processed during run-time. There is no need to generate
huge configuration scripts (like GNU Autoconf does). Debugging becomes
simpler, and the use of third-party features is immediate.

* Menu:

* Scripts::           How scripts are organized.
* Directories::       Defining customizable directories.
* Features::          Defining customizable features.
* Variable types::    Types of variables used by bt_config.
* Checks::            Standard checks.
* Output::            Generating output files.
* Languages::         Selecting a programming language.
* Subroutines::       Using loadable modules.

   ---------- Footnotes ----------

   (1) We say "auto" because it is unattended.


File: buildtool.info,  Node: Scripts,  Next: Directories,  Prev: Configuration,  Up: Configuration

Script organization
===================

   The configuration script is splitted in two files (located insie the
control directory): `config_init' and `config'. To understand this
distinction you should learn how bt_config works internally, described
here:

  1. Load the base module, which provides enough functionality for
     scripts to work.

  2. Read and execute the `config_init' script.

  3. Parse command line arguments, changing bt_config's behavior if
     needed.

  4. Call to the `bt_init' function.

  5. Read and execute the `config' script.

  6. Call to the `bt_finish' function.

   As you have seen, there is an intermediate step between each file
parsing; this is why the whole configuration script is splitted in two
independant blocks.

   The following is a description of the steps taken inside the
`config_init' script:

  1. Define customizable directories.

  2. Define customizable features.

  3. Load third-party modules. These can also add customizable
     directories and/or features.

   And these are the steps taken in the `config' script:

  1. Checks for programs, headers, libraries, etc.

  2. Generation of files, containing the results of the above checks.


File: buildtool.info,  Node: Directories,  Next: Features,  Prev: Scripts,  Up: Configuration

Customizable directories
========================

   Any directory used to install files or where your package expects to
find files should be customizable by the end user. That is, paths must
not be hardcoded in your program but instead use variables that contain
the values selected during configuration time. You will usually want to
provide defaults to these values, though.

   The most important directory that is always available for
customization is the _installation prefix_, contained in the BT_PREFIX
variable. All other directories should be contained inside this one,
following the standard hierarchy.

   To illustrate how to define a customizable directory, we will use an
example. Suppose you want to install a serie of documents in a
non-standard subdirectory, `$BT_PREFIX/doc'. As this is not standard,
it is not directly known by Buildtool, so we will add it. The following
two lines do the trick:

     BT_DIR_DOC="$BT_PREFIX/doc" # This goes in buildtool.d/defs.
     bt_dir "DOC"                # This goes in buildtool.d/config_init.

   The first line sets the default value for the directory. The variable
is named like this: the `BT_DIR_' prefix followed by the name of the
directory used when defining it (see below).

   The second line defines the customizable directory. The call to the
`bt_dir' function takes one or more arguments, which contain the names
of each customizable directory. Note that this name does not need to
match the real name of the directory, and is usually in uppercase.

   Buildtool provides a serie of predefined customization directories.
These are: BIN, ETC, INCLUDE, INFO, LIB, LIBDATA, LIBEXEC, MAN, SBIN,
SHARE and VAR.


File: buildtool.info,  Node: Features,  Next: Variable types,  Prev: Directories,  Up: Configuration

Customizable features
=====================

   A customizable feature is a feature that can be manually selected by
the user during configuration time. This can vary from the selection of
support for a specific library to the decision of not to build concrete
parts of your package (like the documentation).

   To illustrate how to define a customizable directory, we will use an
example, just as we did with directories. Suppose that your program has
optional support for OpenSSL, and you want to let the user select what
to do with it. You define a feature to specify this behavior:

     BT_FEATURE_OPENSSL="yes" # This goes in buildtool.d/defs.
     bt_feature "OPENSSL"     # This goes in buildtool.d/config_init.

   The first line defines the default value for the feature. The value
can be either `yes', `no' or any special value you may consider
necessary (note that these special values will be always treated as
`yes'). The naming convention of features is: the `BT_FEATURE_' prefix
followed by feature's name (see below).

   The second line adds the feature to the list of known features,
defining its name. You should name features in uppercase.


File: buildtool.info,  Node: Variable types,  Next: Checks,  Prev: Features,  Up: Configuration

Types of variables
==================

   Checks' results are placed in variables. These results are then
stored in specific files that are used by other modules and/or sources
to know what configuration did. Depending on where variables are stored,
they have an specific name. The following table contains a list of
recognized types; we will see later how to define them:

`Substitution variables'
     These are environment variables, with the property that they are
     replaced in output files and stored in `bt_config.mk' and/or
     `bt_config.env'. Substitution in output files is done by looking
     for the variable name surrounded by the `@' character. That is,
     @VARIABLE@ is substituted by the contents of VARIABLE.

`Defines'
     These are stored in the `bt_config.h' file to tell C/C++ source
     files which features are available. These are not environment
     variables, therefore, they need to be set with special functions.

   To manage the above variables you need to use special functions
provided by bt_config. The following table contains a summary of them:

`bt_define <macro> [value]'
     Define a macro in the defines list, with an optional value
     surrounded by quotes. The result in `bt_config.h' is something
     like:

          #define macro "value"

`bt_define_unquoted <macro> [value]'
     Define a macro in the defines list, with an optional value not
     surrounded by any character. The result in `bt_config.h' is
     something like:

          #define macro value

`bt_subst <var_name ...>'
     Add the specified variables to the substitution list. You only
     need to add them once. It does not matter where you call this
     function, with the exception that only variables added before
     generating files will be substituted.


File: buildtool.info,  Node: Checks,  Next: Output,  Prev: Variable types,  Up: Configuration

Standard checks
===============

   The base module provides several checks, grouped in different
categories. These include: program checks, header checks, library
checks and miscellaneous checks.

   Most checks return a boolean value indicating if they succeeded or
not. As checks are shell function, `0' means a true value while
anything different than it means false.

* Menu:

* Environment checking::      Automated checks for building environments.
* Program checking::          Compilers, utilities or generic programs.
* Header checking::           Header files that may be missing.
* Library checking::          Libraries that may be missing.
* Miscellaneous checking::    Checks that do not match other types.


File: buildtool.info,  Node: Environment checking,  Next: Program checking,  Prev: Checks,  Up: Checks

Environment checking
--------------------

   These functions provide checks to automatically detect compilation
environments. That is, they check for the compiler, the linker, the
preprocessor and required headers or libraries. Use these functions
instead of independant checks.

`bt_check_env_c'
     Search for a compilation environment for the C language.

`bt_check_env_cxx'
     Search for a compilation environment for the C++ language.


File: buildtool.info,  Node: Program checking,  Next: Header checking,  Prev: Environment checking,  Up: Checks

Program checking
----------------

   You must check for any program you need to build your program. This
way, you can be sure that all programs will be available; also, the end
user will be allowed to modify default programs found to their
preferred ones.

   Programs are searched in the path, by order. The path is read from
the `BT_PATH' environment variable which, if empty, inherits the
contents of `PATH'.

   These checks return `0' on success, `1' otherwise.

`bt_check_progs <var_name> <prog_list> [opt_path]'
     Search for all programs contained in the whitespaced list
     PROG_LIST. Programs are searched in the current path or in
     OPT_PATH if specified. When a program is found, VAR_NAME is set to
     the full pathnam; the variable should be something like
     `BT_PROG_FOOPROGRAM'. Examples:

          bt_check_progs "BT_PROG_CC" "cc gcc bcc"
          bt_check_progs "BT_PROG_CC" "cc gcc bcc" "/opt/bin:/bin:$BT_PATH"

`bt_check_prog_awk'
     Search for an AWK interpreter and set BT_PROG_AWK to its full
     path. The following binaries are searched: `gawk nawk awk'.

`bt_check_prog_cc'
     Search for a C compiler and check if it works properly. It will
     look for the following binaries: `cc gcc bcc'. If no compiler is
     found, the configuration process is aborted; otherwise BT_PROG_CC
     is set to the compiler binary path. The following variables are
     added to the substiution list: BT_FLAGS_CPP, BT_FLAGS_CC and
     BT_LIBS.

`bt_check_prog_cpp'
     Search for a C/C++ preprocessor. If found, BT_PROG_CPP is set to
     the preprocessor binary path. BT_FLAGS_CPP is added to the
     substitution list.

`bt_check_prog_cxx'
     Search for a C++ compiler and check if it works properly. It will
     look for the following binaries: `c++ g++ gcc CC cxx cc++'. If no
     compiler is found, the configuration process is aborted; otherwise
     BT_PROG_CXX is set to the compiler binary path. The following
     variables are added to the substiution list: BT_FLAGS_CPP,
     BT_FLAGS_CXX, and BT_LIBS.

`bt_check_prog_info'
     Search several required tools to generate Info documentation. You
     need this if you plan to use the `bt.info.mk' Makefile. This
     function will locate `makeinfo' and `install-info' programs and
     set BT_PROG_MAKEINFO and BT_PROG_INSTALLINFO accordingly.

`bt_check_prog_ld'
     Search for a linker and set BT_PROG_LD to its full path. The
     following binaries are searched: `ld'.

`bt_check_prog_lex'
     Search for a lex program. It will look for the following binaries:
     `flex lex', setting BT_PROG_LEX to the appropiate binary. If
     `flex' is found, BT_LIBS_LEX is set to `-lfl'; if `lex' is found,
     this variable is set to `-ll' instead.

`bt_check_prog_sh'
     Search for a bourne shell interpreter. It will look for the
     following binaries: `ksh pdksh sh bash zsh'. BT_PROG_SH is set to
     the interpreter binary path.

`bt_check_prog_yacc [proglist]'
     Search for a yacc program. The following binaries are tried, in
     order: `bison byacc yacc'. The optional argument PROGLIST can
     contain a list of programs which overrides the internal one (this
     should be _only_ used if you want to skip Bison check). If any of
     the binaries is found, BT_PROG_YACC is set to the binary path.


File: buildtool.info,  Node: Header checking,  Next: Library checking,  Prev: Program checking,  Up: Checks

Header checking
---------------

   Depending on the nature of your program, you may require to include
some header files that are not standard across operating systems. For
all these non-standard headers, you must include checks inside the
configuration script, so you can see if they are present or not. After
the check, you can decide if you do not include the header or you
include another one that provides what you need.

   Header checks are affected by the current language. To be safe, you
should define include directories in the BT_FLAGS_CPP variable, so they
affect all compilers that use the standard preprocessor.

   These checks return `0' on success, `1' otherwise.

`bt_check_hdr <hdr_name>'
     Check if the specified header HDR_NAME is available and define
     BT_HAVE_HDR_HDRNAME with an empty value. Example:

          bt_check_hdr "malloc.h"

     If this check is successful, the following is added to
     `bt_config.h':

          #define BT_HAVE_HDR_MALLOC_H

`bt_check_hdr_std'
     Checks for several standard headers: `stdio.h', `sys/types.h',
     `sys/stat.h', `string.h', `stdlib.h' and `unistd.h'. Each detected
     header is added to the BT_INCLUDE_FILES list. This list specifies
     which header files need to be included in test programs in order
     to successfully do the tests.

     You _must_ call this function before you do any header or library
     check if you do not really know what you are doing.


File: buildtool.info,  Node: Library checking,  Next: Miscellaneous checking,  Prev: Header checking,  Up: Checks

Library checking
----------------

   If you need to use any special library to link your program, you must
check for it. Similary, you may want to search for specific functions
inside libraries.

   Library checks are affected by the current language. To be safe, you
should define library directories in the BT_FLAGS_CPP variable, so they
affect all compilers that use the standard preprocessor.

   These checks return `0' on success, `1' otherwise.

`bt_check_lib <lib_name> [func_name]'
     Check for the library LIB_NAME and, optionally, for the function
     FUNC_NAME. On success, BT_HAVE_LIB_LIBNAME is defined if you did
     not specify any function; if you did, BT_HAVE_FUNC_FUNCNAME is
     defined instead. Even more, the library is also added to the
     BT_LIBS variable. Examples:

          bt_check_lib "glib"
          bt_check_lib "glib" "g_list_alloc"

     These would add, respectively, the following lines to
     `bt_config.h':

          #define BT_HAVE_LIB_GLIB
          #define BT_HAVE_FUNC_G_LIST_ALLOC

     Note that you are strongly encouraged to call `bt_check_hdr_std'
     before you do any library check (so BT_INCLUDE_FILES gets defined
     properly), unless you know what you are doing.

`bt_check_lib_howto'
     Determine _how_ to build libraries in the current system. The
     first step is to check if dynamic libraries are supported. If they
     are, static libraries are disabled. If not, they are enabled. Note
     that static library support is _always_ provided so that you can
     use static archives internally in your program.


File: buildtool.info,  Node: Miscellaneous checking,  Prev: Library checking,  Up: Checks

Miscellaneous checking
----------------------

   This section contains several checks that do not fit other
categories, but are also useful.

   These checks return `0' on success, `1' otherwise.

`bt_check_bits'
     Determine appropiate C/C++ types for specific sizes in bits. It
     checks for several common types, searching for the following
     sizes: 8 bits, 16 bits, 32 bits and 64 bits (if available). The
     following variables are defined, which contain the type for each
     size:

        * BT_TYPE_BITS8_S

        * BT_TYPE_BITS8_U

        * BT_TYPE_BITS16_S

        * BT_TYPE_BITS16_U

        * BT_TYPE_BITS32_S

        * BT_TYPE_BITS32_U

        * BT_TYPE_BITS64_S

        * BT_TYPE_BITS64_U

     The `S' prefix specifies a signed int type while `U' stands for
     unsigned. Note that these variables are also defined in the
     environment for your convenience.

`bt_check_host'
     Guess several host machine/os related details. The following is
     done by this function:

       1. BT_HOST_OS is set to the name of the host operating system.

       2. BT_HOST_TYPE is set to a string that contains the name of the
          operating system, plus its version, plus the machine
          arquitecture name.

`bt_check_pkgflags <pkg_name> [version_str]'
     This check is quite complex. It uses `pkg-config', if found, to
     determine package flags; if not found, it tries the same with
     `pkg_name-config'. If any of these checks succeed,
     BT_FLAGS_PKGNAME_CC and BT_FLAGS_PKGNAME_LIBS are set to the
     results.

`bt_check_sizeof <type_name>'
     Determine the size of the specified type. If the type is found,
     BT_SIZEOF_TYPENAME is set to type's size. If a pointer sign is
     inside the type, it is replaced by the substring `_PTR_'.  Example:

          bt_check_sizeof "unsigned char *"

     The result in `bt_config.h' is something like:

          #define BT_SIZEOF_UNSIGNED_CHAR_PTR 4

     It also defines an environment variable with the same name, so you
     can check its value to take decisions during configuration. It is
     not added to the substitution list.

`bt_check_type <type_name>'
     Check if the specified type is defined. This check is highly
     affected by the contents of the BT_INCLUDE_FILES files (as the
     files here define which types are available). If the type is found,
     BT_HAVE_TYPE_TYPENAME is defined in the configuration header.


File: buildtool.info,  Node: Output,  Next: Languages,  Prev: Checks,  Up: Configuration

Generating output files
=======================

   After doing all configuration checks you need to store the results
(that is, you should generate files at the _end_ of the script).
Although, you may also want to store results in strategic points inside
the configuration script (be careful).

   The following functions are available:

`bt_generate_output <files ...>'
     Create the specified files from their respective `.in'. Files are
     searched for all variables in the substitution list as `@VARNAME@'
     and replaced by their contents at the moment of the substitution.
     This is not required for Makefile's as in GNU Autoconf, because we
     have an alternative: the configuration Makefile (`bt_config.mk').
     Example:

          bt_generate_output "test/myscript"

     This will generate `test/myscript' from `test/myscript.in' using
     substitution.

`bt_generate_configh [h_name]'
     Generate a configuration C header file, which contains definitions
     from the definitions list. You may optionally specify a header
     name, which defaults to `bt_config.h'.

`bt_generate_configmk [mk_name]'
     Generate a configuration Makefile, which contains all the variables
     from the substitution list. You may optionally specify a file name,
     which defaults to `bt_config.mk'. This file is a must if you want
     to use bt_make Makefile's.

     This function is automatically called at the end of the
     configuration script.

`bt_generate_configenv [env_name]'
     Generate a configuration script, which contains all the variables
     from the substitution list. You may optionally specify a script
     name, which defaults to `bt_config.env'.

     This function is automatically called at the end of the
     configuration script.


File: buildtool.info,  Node: Languages,  Next: Subroutines,  Prev: Output,  Up: Configuration

Language support
================

   Buildtool supports several programming languages internally: C (named
`c') and C++ (named `cxx'). Depending on the selected language, checks
behave different (they use different include directories, different
compiler, etc).

   The following functions are available to manage languages:

`bt_language_select'
     Select a language. By default `c' is used.


File: buildtool.info,  Node: Subroutines,  Prev: Languages,  Up: Configuration

Loadable modules
================

   We try to maintain bt_config's core module (`base.subr') as a simple
and single unit. It supports checks for most of the common things (like
headers, libraries, etc.), but we cannot provide specific checks for
everything. For this reason, bt_config has support for loadable modules
(or _subroutine packages_). A _module_ is an independant entity that
provides its own checks, ready to be used by the package developer.

   Lets illustrate why modules are useful with an example: suppose you
are a GNOME developer that maintains several different programs for
this development platform. For each different package, you will usually
need to do the same checks and provide a common interface to the
configuration process; for example, you will want that all those
packages contain a customizable directory to specify where to install
pixmaps or sound files. You will almost always need to do some
initialization, like checking for Glib or Gtk. So you can put all this
logic together in a module and then use it from all of your packages;
if it happens to be a bug in the module, you will have to fix that
once, and all packages will take benefit of it.

   The other advantadge of modules is that they do _not_ need to be
incorporated inside Buildtool's distribution file. This allows for
distributed development: the GNOME's module depender will not rely on
us to introduce updates inside our sources, and we will avoid ourself
to maintain checks for software that we do not know well. It also
allows the development of modules with different licenses than the BSD
license. Even though, there are times when we may incorporate some
modules inside our distribution file, because they are used by many
programs and it is stupid to distribute them as a separate entity.

   If you are writing an external module and want to install it on any
system, you can run the following command and capture its output (which
will be the right directory to install the file):

     buildtool siteinfo dirsubr

   Now it is time to learn how to load a module in your configuration
script. Module loading is usually done inside `config_init'; this way,
they can provide customizable features and directories. Continuing with
our GNOME example, you could simply do:

     bt_subrload "gnome"
     # Issue module initialization calls here, if wanted.

   After this, all module's functions become available in the
configuration script.

   The following modules come with Buildtool:

* Menu:

* pkgconfig::    Use pkg-config to check for module flags.
* pthread::      Automatic detection of a POSIX threading library.
* x11::          Locate X Window System headers and libraries.


File: buildtool.info,  Node: pkgconfig,  Next: pthread,  Prev: Subroutines,  Up: Subroutines

Module flags
------------

   The `pkgconfig.subr' module provides automatic detection of module
flags.

   After loading this module, you can use the following functions inside
`config':

`pkgconfig_check <module_name> <version_string>'
     Determine compiler and linker flags for the specified module.
     This function returns 0 on success or 1 on error. After a
     successful detection, PKGCONFIG_FLAGS_<MODNAME>_CC and
     PKGCONFIG_FLAGS_<MODNAME>_LIBS are set accordingly to the specific
     module.


File: buildtool.info,  Node: pthread,  Next: x11,  Prev: pkgconfig,  Up: Subroutines

POSIX threads
-------------

   The `pthread.subr' module provides automatic detection of a POSIX
threading library.

   After loading this module, you can use the following functions inside
`config_init':

`pthread_feature'
     Define a customizable feature, called `PTHREAD' (which defaults to
     `yes'), that can be used to disable manually the threading
     libraries in programs that may be compiled with and without them.
     You should not use this function if you rely on a threading
     library to run properly.

   And these functions are available in the `config' file:

`pthread_check'
     Automatically check for a threading library in the current system.
     This function returns 0 on success or 1 on error. After a
     successful detection, PTHREAD_FLAGS_LD and PTHREAD_LIBS are set
     accordingly to the specific library found. You should then use
     these variables in Makefiles for programs that need threads. As an
     example, you may do inside a `Makefile':

          BT_FLAGS_LD+= ${PTHREAD_FLAGS_LD}
          BT_LIBS+= ${PTHREAD_LIBS}


File: buildtool.info,  Node: x11,  Prev: pthread,  Up: Subroutines

X Window System
---------------

   The `x11.subr' module provides automatic detection of the X Window
System development files.

   After loading this module, you can use the following functions inside
`config_init':

`x11_feature'
     Define a customizable feature, called `X11' (which defaults to
     `yes'), that can be used to disable manually the X11 libraries in
     programs that may be compiled with and without them. You should
     not use this function if your program uses X11 unconditionally.

   And these functions are available in the `config' file:

`x11_check'
     Automatically check for X11 headers and libraries.  This function
     aborts the configuration if X11 is not found.  After a successful
     detection, X11_FLAGS_CPP and X11_FLAGS_LD are set accordingly to
     the specific stuff found. You should then use these variables in
     Makefiles for programs that need X11. As an example, you may do
     inside a `Makefile':

          BT_FLAGS_CPP+= ${X11_FLAGS_CPP}
          BT_FLAGS_LD+= ${X11_FLAGS_LD}


File: buildtool.info,  Node: Makefiles,  Next: Installation,  Prev: Configuration,  Up: Top

Makefile infrastructure
***********************

   Buildtool provides a regular make tool called bt_make; it is based on
NetBSD's pmake. Aside from the module, it also provides several
Makefiles to easily perform very different tasks; these form the
_Makefile infrastrucure_.

   bt_make requires a `bt_config.mk' file to be present in package's
top directory, so add a call to `bt_generate_configmk' in your
configuration script, *Note Output::.

   Note that most of the documentation included here has been taken from
make's original manpage and the document `/usr/share/mk/bsd.README'
distributed with NetBSD.

* Menu:

* Comments::           Adding explanations.
* Dependancies::       File dependancy specification.
* Shell commands::     Running shell commands.
* Variables::          Variable assignments.
* File inclusion::     How to include other Makefiles.
* Conditionals::       Checking for conditions.
* Loops::              Repeating commands.
* Special sources::    Special sources.
* Special targets::    Special targets.
* bt.prog.mk::         Program's framework.
* bt.lib.mk::          Library's framework.
* bt.man.mk::          Manual pages.
* bt.inc.mk::          Header installation.
* qt.moc.mk::          Generating QT's moc files.


File: buildtool.info,  Node: Comments,  Next: Dependancies,  Prev: Makefiles,  Up: Makefiles

Comments
========

   Comments begin with a hash `#' character, anywhere but in a shell
command line, and continue to the end of the line.

   It is important that you add comments in your Makefiles, so end-users
can understand what you are doing.


File: buildtool.info,  Node: Dependancies,  Next: Shell commands,  Prev: Comments,  Up: Makefiles

File dependancy specification
=============================

   Dependency lines consist of one or more targets, an operator, and
zero or more sources. This creates a relationship where the targets
"depend" on the sources and are usually created from them. The exact
relationship between the target and the source is determined by the
operator that separates them. The three operators are as follows:

`:'
     A target is considered out-of-date if its modification time is less
     than those of any of its sources. Sources for a target accumulate
     over dependency lines when this operator is used. The target is
     removed if bt_make is interrupted.

`!'
     Targets are always re-created, but not until all sources have been
     examined and re-created as necessary. Sources for a target
     accumulate over dependency lines when this operator is used. The
     target is removed if bt_make is interrupted.

`::'
     If no sources are specified, the target is always re-created.
     Otherwise, a target is considered out-of-date if any of its sources
     has been modified more recently than the target. Sources for a
     target do not accumulate over dependency lines when this operator
     is used.  The target will not be removed if bt_make is interrupted.

   Targets and sources may contain the shell wildcard values `?', `*',
`[]' and `{}'. The values `?', `*' and `[]' may only be used as part of
the final component of the target or source, and must be used to
describe existing files. The value `{}' need not necessarily be used to
describe existing files. Expansion is in directory order, not
alphabetically as done in the shell.


File: buildtool.info,  Node: Shell commands,  Next: Variables,  Prev: Dependancies,  Up: Makefiles

Shell commands
==============

   Each target may have associated with it a series of shell commands,
normally used to create the target. Each of the commands in this script
_must_ be preceded by a <TAB>. While any target may appear on a
dependency line, only one of these dependencies may be followed by a
creation script, unless the `::' operator is used.

   If the first or first two characters of the command line are `@'
and/or `-', the command is treated specially. A `@' causes the command
not to be echoed before it is executed. A `-' causes any non-zero exit
status of the command line to be ignored.


File: buildtool.info,  Node: Variables,  Next: File inclusion,  Prev: Shell commands,  Up: Makefiles

Variable assignments
====================

   Variables in make are much like variables in the shell and, by
tradition, consist of all upper-case letters.

   The five operators that can be used to assign values to variables are
as follows:

`='
     Assign the value to the variable. Any previous value is overridden.

`+='
     Append the value to the current value of the variable.

`?='
     Assign the value to the variable if it is not already defined.

`:='
     Assign with expansion, i.e. expand the value before assigning it to
     the variable. Normally, expansion is not done until the variable is
     referenced.

`!='
     Expand the value and pass it to the shell for execution and assign
     the result to the variable. Any newlines in the result are
     replaced with spaces.

   Any white-space before the assigned `value' is removed; if the value
is being appended, a single space is inserted between the previous
contents of the variable and the appended value.

   Variables are expanded by surrounding the variable name with either
curly braces `{}' or parentheses `()' and preceding it with a dollar
sign `$'. If the variable name contains only a single letter, the
surrounding braces or parentheses are not required.  This shorter form
is _not_ recommended.

   Variable substitution occurs at two distinct times, depending on
where the variable is being used. Variables in dependency lines are
expanded as the line is read. Variables in shell commands are expanded
when the shell command is executed.

   The four different classes of variables (in order of increasing
precedence) are:

`Environment variables'
     Variables defined as part of bt_make's environment.

`Global variables'
     Variables defined in the makefile or in included makefiles.

`Command line variables'
     Variables defined as part of the command line.

`Local variables'
     Variables that are defined specific to a certain target. The seven
     local variables are as follows:

    .ALLSRC
          The list of all sources for this target; also known as >.

    .ARCHIVE
          The name of the archive file.

    .IMPSRC
          The name/path of the source from which the target is to be
          transformed (the "implied" source); also known as <.

    .MEMBER
          The name of the archive member.

    .OODATE
          The list of sources for this target that were deemed
          out-of-date; also known as ?.

    .PREFIX
          The file prefix of the file, containing only the file
          portion, no suffix or preceding directory components; also
          known as *.

    .TARGET
          The name of the target; also known as @.

     The shorter forms @, ?, <, > and * are permitted for backward
     compatibility with historical makefiles and are not recommended.
     The six variables @F, @D, <F, <D, *F and *D are permitted for
     compatibility with AT&T System V UNIX makefiles and are not
     recommended.

     Four of the local variables may be used in sources on dependency
     lines because they expand to the proper value for each target on
     the line.  These variables are .TARGET, .PREFIX, .ARCHIVE, and
     .MEMBER.

   In addition, bt_make sets or knows about the following variables:

$
     A single dollar sign `$', i.e. $$ expands to a single dollar sign.

.ALLTARGETS
     The list of all targets encountered in the Makefile.  If evaluated
     during Makefile parsing, lists only those targets encountered thus
     far.

.CURDIR
     A path to the directory where bt_make was executed.

.MAKE
     The name that bt_make was executed with.

MAKEFLAGS
     The environment variable MAKEFLAGS may contain anything that may
     be specified on bt_make's command line. Anything specified on
     bt_make's command line is appended to the MAKEFLAGS variable which
     is then entered into the environment for all programs which
     bt_make executes.

.MAKEOVERRIDES
     This variable is used to record the names of variables assigned to
     on the command line, so that they may be exported as part of
     MAKEFLAGS. This behaviour can be disabled by assigning an empty
     value to .MAKEOVERRIDES within a makefile. Extra variables can be
     exported from a makefile by appending their names to
     .MAKEOVERRIDES. MAKEFLAGS is re-exported whenever .MAKEOVERRIDES
     is modified.

MAKE_PRINT_VAR_ON_ERROR
     When bt_make stops due to an error, it prints its name and the
     value of .CURDIR as well as the value of any variables named in
     MAKE_PRINT_VAR_ON_ERROR .

.NEWLINE
     This variable is simply assigned a newline character as its value.
     This allows expansions using the : modifier to put a newline
     between iterations of the loop rather than a space.  For example,
     the printing of MAKE_PRINT_VAR_ON_ERROR could be done as
     `${MAKE_PRINT_VAR_ON_ERROR:@v@$v='${$v}'${.newline}}'.

.OBJDIR
     A path to the directory where the targets are built.

.PARSEDIR
     A path to the directory of the current `Makefile.bt' being parsed.

.PARSEFILE
     The basename of the current `Makefile.bt' being parsed. This
     variable and .PARSEDIR are both set only while the `Makefiles' are
     being parsed.

PWD
     Alternate path to the current directory. bt_make normally sets
     .CURDIR to the canonical path given by `getcwd'. However, if the
     environment variable PWD is set and gives a path to the current
     directory, then bt_make sets .CURDIR to the value of PWD instead.
     This behaviour is disabled if MAKEOBJDIRPREFIX is set. PWD is set
     to the value of .OBJDIR for all programs which bt_make executes.

   Variable expansion may be modified to select or modify each word of
the variable (where a "word" is white-space delimited sequence of
characters). The general format of a variable expansion is as follows:

     {variable[:modifier[:...]]}

   Each modifier begins with a colon and one of the following special
characters. The colon may be escaped with a backslash `\'.

`E'
     Replaces each word in the variable with its suffix.

`H'
     Replaces each word in the variable with everything but the last
     component.

`M<pattern>'
     Select only those words that match the rest of the modifier.  The
     standard shell wildcard characters `*', `?', and `[]', may be
     used. The wildcard characters may be escaped with a backslash `\'.

`N<pattern>'
     This is identical to `M', but selects all words which do not match
     the rest of the modifier.

`O'
     Order every word in variable alphabetically.

`Q'
     Quotes every shell meta-character in the variable, so that it can
     be passed safely through recursive invocations of bt_make.

`R'
     Replaces each word in the variable with everything but its suffix.

`tl'
     Converts variable to lower-case letters.

`tu'
     Converts variable to upper-case letters.

`S/<old_string>/<new_string>/[1g]'
     Modify the first occurrence of OLD_STRING in the variable's value,
     replacing it with NEW_STRING. If a `g' is appended to the last
     slash of the pattern, all occurrences in each word are replaced.
     If a `1' is appended to the last slash of the pattern, only the
     first word is affected. If OLD_STRING begins with a caret `^',
     OLD_STRING is anchored at the beginning of each word. If
     OLD_STRING ends with a dollar sign `$', it is anchored at the end
     of each word. Inside NEW_STRING, an ampersand `&' is replaced by
     OLD_STRING (without any `^' or `$'). Any character may be used as
     a delimiter for the parts of the modifier string. The anchoring,
     ampersand and delimiter characters may be escaped with a backslash
     `\'.

     Variable expansion occurs in the normal fashion inside both
     OLD_STRING and NEW_STRING with the single exception that a
     backslash is used to prevent the expansion of a dollar sign `$'
     not a preceding dollar sign as is usual.

`C/<pattern>/replacement/[1g]'
     The `C' modifier is just like the `S' modifier except that the old
     and new strings, instead of being simple strings, are a regular
     expression and an `ed'-style replacement string. Normally, the
     first occurrence of the pattern in each word of the value is
     changed. The `1' modifier causes the substitution to apply to at
     most one word; the `g' modifier causes the substitution to apply
     to as many instances of the search pattern as occur in the word or
     words it is found in. Note that `1' and `g' are orthogonal; the
     former specifies whether multiple words are potentially affected,
     the latter whether multiple substitutions can potentially occur
     within each affected word.

`T'
     Replaces each word in the variable with its last component.

`u'
     Remove adjacent duplicate words (like the `uniq' command).

`? <true_string> : <false_string>'
     If the variable evaluates to true, return as its value the
     TRUE_STRING, otherwise return the FALSE_STRING.

`old_string=new_string'
     This is the AT&T System V UNIX style variable substitution.  It
     must be the last modifier specified.  If OLD_STRING or NEW_STRING
     do not contain the pattern matching character `%' then it is
     assumed that they are anchored at the end of each word, so only
     suffixes or entire words may be replaced. Otherwise `%' is the
     substring of OLD_STRING to be replaced in NEW_STRING.

`@ <temp> @ <string> @'
     This is the loop expansion mechanism from the OSF Development
     Environment (ODE) make. Unlike `.for' loops expansion occurs at
     the time of reference. Assign TEMP to each word in the variable
     and evaluate STRING. The ODE convention is that TEMP should start
     and end with a period. For example:

          ${LINKS:@.LINK.@${LN} ${TARGET} ${.LINK.}@}

`U <newval>'
     If the variable is undefined NEWVAL is the value. If the variable
     is defined, the existing value is returned. This is another ODE
     make feature. It is handy for setting per-target CFLAGS for
     instance:

          ${_${.TARGET:T}_CFLAGS:U${DEF_CFLAGS}}

     If a value is only required if the variable is undefined, use:

          ${VAR:D:Unewval}

`D <newval>'
     If the variable is defined NEWVAL is the value.

`L'
     The name of the variable is the value.

`P'
     The path of the node which has the same name as the variable is the
     value. If no such node exists or its path is null, then the name of
     the variable is used.

`! <cmd> !'
     The output of running CMD is the value.

`sh'
     If the variable is non-empty it is run as a command and the output
     becomes the new value.

`:= <str>'
     The variable is assigned the value STR after substitution. This
     modifier and its variations are useful in obscure situations such
     as wanting to apply modifiers to `.for' loop iteration variables
     which won't work due to the way `.for' loops are implemented.
     These assignment modifiers always expand to nothing, so if
     appearing in a rule line by themselves should be preceded with
     something to keep bt_make happy. As in:

          use_foo: .USE
          .for i in ${.TARGET} ${.TARGET:R}.gz
                  @: ${t::=$i}
                  @echo t:R:T=${t:R:T}
          .endfor

     The double `:' helps avoid false matches with the AT&T System V
     UNIX style `=' modifier and since substitution always occurs the
     `:=' form is vaguely appropriate.

`:?= <str>'
     As for `:=' but only if the variable does not already have a value.

`:+= <str>'
     Append STR to the variable.

`:!= <cmd>'
     Assign the output of CMD to the variable.


File: buildtool.info,  Node: File inclusion,  Next: Conditionals,  Prev: Variables,  Up: Makefiles

File inclusion
==============

   Files are included with either `.include <file>' or `.include
"file"'. Variables between the angle brackets or double quotes are
expanded to form the file name. If angle brackets are used, the
included makefile is expected to be in the system makefile directory.
If double quotes are used, the including makefile's directory and any
directories specified using the `-I' option are searched before the
system makefile directory.  For compatibility with other versions of
`make' `include file' is also accepted. If the include statement is
written as `.-include' or as `.sinclude' then errors locating and/or
opening include files are ignored.

   Makefiles processed by bt_make will usually have the following
include structure:

     # Include bt_config.mk, from top's directory.
     .include "../bt_config.mk"
     
     # Makefile regular stuff
     
     # Include Buildtool Makefile Infrastructure.
     .include <bt.prog.mk>

   As you see, the first call includes the configuration makefile
generated by the bt_config module. You might omit this inclusion, as it
will be included by default, at the _end_ of the file; therefore, you
are recommended to include it by hand, so you can use its contents
safely.

   The last line includes a makefile which is part of Buildtool's
Makefile Infrastructure (this one is designed to build programs).


File: buildtool.info,  Node: Conditionals,  Next: Loops,  Prev: File inclusion,  Up: Makefiles

Conditionals
============

   Conditional expressions are also preceded by a single dot as the
first character of a line. The possible conditionals are as follows:

`.undef <variable>'
     Un-define the specified global variable. Only global variables may
     be un-defined.

`.if [!]expression [operator expression ...]'
     Test the value of an expression.

`.ifdef [!]variable [operator variable ...]'
     Test the value of a variable.

`.ifndef [!]variable [operator variable ...]'
     Test the value of a variable.

`.ifmake [!]target [operator target ...]'
     Test the target being built.

`.ifnmake [!]target [operator target ...]'
     Test the target being built.

`.else'
     Reverse the sense of the last conditional.

`.elif [!]expression [operator expression ...]'
     A combination of `.else' followed by `.if'.

`.elifdef [!]variable [operator variable ...]'
     A combination of `.else' followed by `.ifdef'.

`.elifndef [!]variable [operator variable ...]'
     A combination of `.else' followed by `.ifndef'.

`.elifmake [!]target [operator target ...]'
     A combination of `.else' followed by `.ifmake'.

`.elifnmake [!]expression [operator target ...]'
     A combination of `.else' followed by `.ifnmake'.

`.endif'
     End the body of the conditional.

   The `operator' may be any one of the following:

`||'
     Logical OR

`&&'
     Logical AND; of higher precedence than `||'.

   As in C, bt_make will only evaluate a conditional as far as is
necessary to determine its value. Parentheses may be used to change the
order of evaluation. The boolean operator `!' may be used to logically
negate an entire conditional. It is of higher precedence than `&&'.

   The value of `expression' may be any of the following:

`defined'
     Takes a variable name as an argument and evaluates to true if the
     variable has been defined.

`make'
     Takes a target name as an argument and evaluates to true if the
     target was specified as part of bt_make's command line or was
     declared the default target (either implicitly or explicitly, XXX
     see .MAIN) before the line containing the conditional.

`empty'
     Takes a variable, with possible modifiers, and evaluates to true if
     the expansion of the variable would result in an empty string.

`exists'
     Takes a file name as an argument and evaluates to true if the file
     exists. The file is searched for on the system search path (XXX see
     .PATH).

`target'
     Takes a target name as an argument and evaluates to true if the
     target has been defined.

`commands'
     Takes a target name as an argument and evaluates to true if the
     target has been defined and has commands associated with it.

   `Expression' may also be an arithmetic or string comparison.
Variable expansion is performed on both sides of the comparison, after
which the integral values are compared. A value is interpreted as
hexadecimal if it is preceded by `0x', otherwise it is decimal; octal
numbers are not supported. The standard C relational operators are all
supported. If after variable expansion, either the left or right hand
side of a `==' or `!=' operator is not an integral value, then string
comparison is performed between the expanded variables. If no
relational operator is given, it is assumed that the expanded variable
is being compared against `0'.

   When bt_make is evaluating one of these conditional expression, and
it encounters a word it doesn't recognize, either the "make" or
"defined" expression is applied to it, depending on the form of the
conditional. If the form is `.ifdef' or `.ifndef', the "defined"
expression is applied. Similarly, if the form is `.ifmake' or
`.ifnmake', the "make" expression is applied.

   If the conditional evaluates to true the parsing of the makefile
continues as before. If it evaluates to false, the following lines are
skipped. In both cases this continues until a `.else' or `.endif' is
found.


File: buildtool.info,  Node: Loops,  Next: Special sources,  Prev: Conditionals,  Up: Makefiles

Loops
=====

   For loops are typically used to apply a set of rules to a list of
files. The syntax of a for loop is:

     .for <variable> [variable ...] in <expression>
             <make-rules>
     .endfor

   After the for `expression' is evaluated, it is split into words. On
each iteration of the loop, one word is taken and assigned to each
VARIABLE, in order, and these VARIABLES are substituted into the
`make-rules' inside the body of the for loop. The number of words must
come out even; that is, if there are three iteration variables, the
number of words provided must be a multiple of three.


File: buildtool.info,  Node: Special sources,  Next: Special targets,  Prev: Loops,  Up: Makefiles

Special sources
===============

`.IGNORE'
     Ignore any errors from the commands associated with this target,
     exactly as if they all were preceded by a dash `-'.

`.MADE'
     Mark all sources of this target as being up-to-date.

`.MAKE'
     Execute the commands associated with this target even if the `-n'
     or `-t' options were specified. Normally used to mark recursive
     bt_make's.

`.NOTMAIN'
     Normally bt_make selects the first target it encounters as the
     default target to be built if no target was specified. This source
     prevents this target from being selected.

`.OPTIONAL'
     If a target is marked with this attribute and bt_make can't figure
     out how to create it, it will ignore this fact and assume the file
     isn't needed or already exists.

`.PRECIOUS'
     When bt_make is interrupted, it removes any partially made targets.
     This source prevents the target from being removed.

`.SILENT'
     Do not echo any of the commands associated with this target,
     exactly as if they all were preceded by an at sign `@'.

`.USE'
     Turn the target into bt_make's version of a macro. When the target
     is used as a source for another target, the other target acquires
     the commands, sources, and attributes (except for `.USE') of the
     source. If the target already has commands, the `.USE' target's
     commands are appended to them.

`.USEBEFORE'
     Exactly like `.USE', but prepend the `.USEBEFORE' target commands
     to the target.

`.WAIT'
     If special `.WAIT' source is appears in a dependency line, the
     sources that precede it are made before the sources that succeed
     it in the line. Loops are not being detected and targets that form
     loops will be silently ignored.


File: buildtool.info,  Node: Special targets,  Next: bt.prog.mk,  Prev: Special sources,  Up: Makefiles

Special targets
===============

   Special targets may not be included with other targets, i.e. they
must be the only target specified.

`.BEGIN'
     Any command lines attached to this target are executed before
     anything else is done.

`.DEFAULT'
     This is sort of a `.USE' rule for any target (that was used only
     as a source) that bt_make can't figure out any other way to create.
     Only the shell script is used.  The .IMPSRC variable of a target
     that inherits `.DEFAULT''s commands is set to the target's own
     name.

`.END'
     Any command lines attached to this target are executed after
     everything else is done.

`.IGNORE'
     Mark each of the sources with the `.IGNORE' attribute.  If no
     sources are specified, this is the equivalent of specifying the
     `-i' option.

`.INTERRUPT'
     If bt_make is interrupted, the commands for this target will be
     executed.

`.MAIN'
     If no target is specified when bt_make is invoked, this target
     will be built.

`.MAKEFLAGS'
     This target provides a way to specify flags for bt_make when the
     makefile is used.  The flags are as if typed to the shell, though
     the `-f' option will have no effect.

`.NOPATH'
     Apply the `.NOPATH' attribute to any specified sources. Targets
     with this attribute are not searched for in the directories
     specified by `.PATH'.

`.NOTPARALLEL'
     Disable parallel mode.

`.NO_PARALLEL'
     Same as above, for compatibility with other pmake variants.

`.ORDER'
     The named targets are made in sequence.

`.PATH'
     The sources are directories which are to be searched for files not
     found in the current directory. If no sources are specified, any
     previously specified directories are deleted. If the source is the
     special `.DOTLAST' target, then the current working directory is
     searched last.

`.PHONY'
     Apply the `.PHONY' attribute to any specified sources. Targets
     with this attribute do not correspond to actual files; they are
     always considered to be out of date, and will not be created with
     the `-t' option.

`.PRECIOUS'
     Apply the `.PRECIOUS' attribute to any specified sources.  If no
     sources are specified, the `.PRECIOUS' attribute is applied to
     every target in the file.

`.SILENT'
     Apply the `.SILENT' attribute to any specified sources.  If no
     sources are specified, the `.SILENT' attribute is applied to every
     command in the file.

`.SUFFIXES'
     Each source specifies a suffix to bt_make.  If no sources are
     specified, any previous specified suffixes are deleted.


File: buildtool.info,  Node: bt.prog.mk,  Next: bt.lib.mk,  Prev: Special targets,  Up: Makefiles

Program's framework
===================

   The include file `bt.prog.mk' handles building programs from one or
more source files, along with their manual pages.

   It uses the following variables:

BT_PROG
     Specifies the program name. This sets BT_SRCS to the program name
     plus a `.c' suffix if it was not already set. It also sets BT_MAN
     to the program name plus a `.1' suffix if it was not already set.

BT_SRCS
     Specifies which sources form the program. These files are scanned
     for dependancies and built according on their format (whether they
     are C or C++, for example).


File: buildtool.info,  Node: bt.lib.mk,  Next: bt.man.mk,  Prev: bt.prog.mk,  Up: Makefiles

Library's framework
===================

   The include file <bsd.lib.mk> has support for building libraries. The
way how libraries are built (dynamic or static) is determined during
configuration time, calling the function `bt_check_lib_howto'.

   It uses the following variables:

BT_LIB
     Specifies the base name of the program (without the `lib' preffix
     and no suffix). This sets BT_SRCS to the library name plus a `.c'
     suffix if it was not already set.

BT_SRCS
     Specifies which sources form the library. These files are scanned
     for dependancies and built according on their format (whether they
     are C or C++, for example).

BT_LIB_MKPIC
     If set to `yes', build a dynamic library. You should _not_ change
     this variable by hand as you can break the build system (dynamic
     libraries are not always available).

BT_LIB_MKSTATIC
     If set to `yes', build a static library.

   You can always set static builds on a per library basis. This is
useful if you want to create a convenience archive inside your sources.
Example: suppose you have several source files that act as helpers and
they need to be statically linked with all other program modules. You
could add the following code to the library's Makefile:

     BT_LIB_MKPIC=no
     BT_LIB_MKSTATIC=yes
     
     install:
             # Internal archive, do nothing.


File: buildtool.info,  Node: bt.man.mk,  Next: bt.inc.mk,  Prev: bt.lib.mk,  Up: Makefiles

Manual pages
============

   The include file `bt.man.mk' handles installing manual pages.  It is
often included automatically by `bt.prog.mk' and `bt.lib.mk', but you
may want to use it standalone.

   It uses the following variables:

BT_MAN
     The manual pages to be installed (use a .1 - .9 suffix).


File: buildtool.info,  Node: bt.inc.mk,  Next: qt.moc.mk,  Prev: bt.man.mk,  Up: Makefiles

Header installation
===================

   The include file `bt.inc.mk' provides installation support of C/C++
header files.

   It uses the following variables:

BT_INCS
     A whitespace separated list of include files to install.

BT_INCSDIR
     The subdirectory where install files should go. If not specified,
     files will be installed directly into BT_DIR_INCLUDE. Note that
     the contents of this variable must be a relative directory from top
     include directory.


File: buildtool.info,  Node: qt.moc.mk,  Prev: bt.inc.mk,  Up: Makefiles

QT's moc file generation
========================

   The QT Toolkit uses a preprocessor, called `moc', that parses
special C++ headers and generates `.moc' files. This preprocessor needs
to be called before dependancies are scanned (so `.moc' files can be
found). This is the job of this extra makefile.

   As `qt.moc.mk' use the moc preprocessor, you must detect it from
your configuration file with this call:

     bt_check_progs "BT_PROG_MOC" "moc"

   `qt.moc.mk' must be included before any Buildtool specific Makefile.
Example:

     .include "../bt_config.mk"
     
     BT_PROG= myprog
     BT_SRCS= myprog.cpp MainWindow.cpp
     
     QT_HDRS= MainWindow.h
     
     # More stuff
     
     .include <qt.moc.mk>
     .include <bt.prog.mk>

   The following table lists all variables recognized by this makefile:

QT_HDRS
     A white-spaced list of C++ header files (`.h') that need to be
     parsed through the moc preprocessor. These files are parsed before
     dependancies, so the regular C preprocessor will not choke on
     missing files.


File: buildtool.info,  Node: Installation,  Next: Documents,  Prev: Makefiles,  Up: Top

Installing files from Makefiles
*******************************

   The bt_logic module provides an easy way to install files on any
system. bt_config automatically configures your Makefiles so they can
use this module easily, so you do not need to worry about its
configuration.

   You just need to know some of the variables defined for you, to be
used in your own Makefiles:

BT_INSTALL_BIN
     Install a binary program or script. The first argument specifies
     the source file and the second the target directory. Multiple
     source files can be specified.

BT_INSTALL_DATA
     Install a data file. The first argument specifies the source file
     and the second the target directory. Multiple source files can be
     specified.

BT_INSTALL_DIR
     Install a new directory.

BT_INSTALL_LIB
     Install a library (either shared or static).

BT_INSTALL_SYMLINK
     Creates a symlink. The first argument specifies the source file and
     the second tells symlink's name.


File: buildtool.info,  Node: Documents,  Next: Verification,  Prev: Installation,  Up: Top

Build related documentation
***************************

   The top directory of a buildtool-ized package is reserved to hold
build related documentation, *Note Top files::. These documents can be
easily browsed using the bt_doc module.

   bt_doc reads the definitions file to get the package name, its
version and its license. Therefore, if the license is known internally
by Buildtool, you do not need to worry about including it in your source
package (they are often huge).

   To know which documents are available, this module reads the `docs'
file inside the control directory, which contains a list of files (with
relative paths from the top-level directory) togheter with their
description. Fields in this file are marked by the sequence ` - '
(whitespace dash whitespace).

   Here is an example of a `docs' file:

     CHANGES - Major changes between package versions
     PEOPLE - Authors and contributors
     README - General documentation
     TODO - Missing things


File: buildtool.info,  Node: Verification,  Next: Distfiles,  Prev: Documents,  Up: Top

Verifying a package
*******************

   Buildtool is complex. Making a package which conforms to all its
features is a hard task, specially if you are a new developer who is
starting to use it. Luckily for you, Buildtool includes a module,
called bt_lint, which verifies your package against common standards
and warns you about wrong things, *Note Package structure::.

   To verify your package, simply do (from the top directory):

     buildtool lint

   It will run some tests and, at the end, show a summary about check
results. There are three types of results: FATAL, WARN and OK. Lets
examine them:

`FATAL'
     Your package misses something _required_ for proper Buildtool
     operation. These will not (usually) refer to missing files.

`WARN'
     Your package is ok, but could be better. Most of the warnings
     refer to some things you may do to make your package better. These
     checks usually refer to missing files or variables not used. You
     may perfectly _omit_ them, as they are only _recommendations_.

`OK'
     Your package is perfect, according to your Buildtool version. A
     successful package should validate perfectly in all Buildtool's
     versions with the same _major number_ than the one you have.


File: buildtool.info,  Node: Distfiles,  Next: Function index,  Prev: Verification,  Up: Top

Generating distribution files
*****************************

   bt_dist is a small module which builds distribution files from your
package. A distribution file is a compressed file that is usually
distributed over the network; for example, source tarballs. Currently,
bt_dist can only build this kind of files (several formats are
supported). It may be that in a future we include support to build
binary packages automatically through bt_dist (i.e. rpm or deb).

   This module is ran using the `dist' target of Buildtool's wrapper.
The steps it does are, in order:

  1. Cleanup the source tree. This is done using bt_make's `cleandir'
     target from the top directory. You should note that this will not
     clean your source tree completly (there may be file backups, etc.)
     that you need to remove by hand. If you do not do it, they will be
     included in the distribution file.

  2. Verify the package. bt_lint is run to test your package validity.
     If it sees any fatal error, the build is stopped (a distribution
     file cannot be built if the package is not valid). Note that
     warnings can be ommited.

  3. Check distribution file types. You should define the variable
     BT_PKG_DISTFMTS in your definitions file to specify default
     distribution file formats. If any format is not known, the build is
     aborted for that format, and other are continued.

  4. Effectively build the package. It will remain in the parent
     directory.

* Menu:

* Known formats::    Recognized distribution formats.


File: buildtool.info,  Node: Known formats,  Prev: Distfiles,  Up: Distfiles

Known formats
=============

   The variable BT_PKG_DISTFMTS can contain several format strings that
determine how the distribution file is built. The following table lists
recognized values (note that the variable can contain several file
types):

`tar.bz2'
     Build a tar'ed, bzip2'ed file. This uses a `.tar.bz2' extension
     for the distribution file.

`tbz'
     Build a tar'ed, bzip2'ed file. This uses a `.tbz' extension for
     the distribution file.

`tar.gz'
     Build a tar'ed, gzip'ed file. This uses a `.tar.gz' extension for
     the distribution file.

`tgz'
     Build a tar'ed, gzip'ed file. This uses a `.tgz' extension for the
     distribution file.

`zip'
     Build a zipped. file This uses a `.zip' extension for the
     distribution file.


File: buildtool.info,  Node: Function index,  Next: Variable index,  Prev: Distfiles,  Up: Top

Function index
**************

* Menu:

* bt_check_bits:                         Miscellaneous checking.
* bt_check_env_c:                        Environment checking.
* bt_check_env_cxx:                      Environment checking.
* bt_check_hdr:                          Header checking.
* bt_check_hdr_std:                      Header checking.
* bt_check_host:                         Miscellaneous checking.
* bt_check_lib:                          Library checking.
* bt_check_lib_howto:                    Library checking.
* bt_check_pkgflags:                     Miscellaneous checking.
* bt_check_prog_awk:                     Program checking.
* bt_check_prog_cc:                      Program checking.
* bt_check_prog_cpp:                     Program checking.
* bt_check_prog_cxx:                     Program checking.
* bt_check_prog_info:                    Program checking.
* bt_check_prog_ld:                      Program checking.
* bt_check_prog_lex:                     Program checking.
* bt_check_prog_sh:                      Program checking.
* bt_check_prog_yacc:                    Program checking.
* bt_check_progs:                        Program checking.
* bt_check_sizeof:                       Miscellaneous checking.
* bt_check_type:                         Miscellaneous checking.
* bt_define:                             Variable types.
* bt_define_unquoted:                    Variable types.
* bt_generate_configenv:                 Output.
* bt_generate_configh:                   Output.
* bt_generate_configmk:                  Output.
* bt_generate_output:                    Output.
* bt_language_select:                    Languages.
* bt_subrload:                           Subroutines.
* bt_subst:                              Variable types.
* pkgconfig_check:                       pkgconfig.
* pthread_check:                         pthread.
* pthread_feature:                       pthread.
* x11_check:                             x11.
* x11_feature:                           x11.


File: buildtool.info,  Node: Variable index,  Prev: Function index,  Up: Top

Variable index
**************

* Menu:

* $:                                     Variables.
* .ALLSRC:                               Variables.
* .ALLTARGETS:                           Variables.
* .ARCHIVE:                              Variables.
* .CURDIR:                               Variables.
* .IMPSRC:                               Variables.
* .MAKE:                                 Variables.
* .MAKEOVERRIDES:                        Variables.
* .MEMBER:                               Variables.
* .newline:                              Variables.
* .OBJDIR:                               Variables.
* .OODATE:                               Variables.
* .PARSEDIR:                             Variables.
* .PARSEFILE:                            Variables.
* .PREFIX:                               Variables.
* .TARGET:                               Variables.
* BT_DIR_BIN:                            Directories.
* BT_DIR_ETC:                            Directories.
* BT_DIR_INCLUDE:                        Directories.
* BT_DIR_INFO:                           Directories.
* BT_DIR_LIB:                            Directories.
* BT_DIR_LIBDATA:                        Directories.
* BT_DIR_LIBEXEC:                        Directories.
* BT_DIR_MAN:                            Directories.
* BT_DIR_SBIN:                           Directories.
* BT_DIR_SHARE:                          Directories.
* BT_DIR_VAR:                            Directories.
* BT_FLAGS_CC:                           Program checking.
* BT_FLAGS_CPP:                          Program checking.
* BT_FLAGS_CXX:                          Program checking.
* BT_INCLUDE_FILES:                      Header checking.
* BT_INCS:                               bt.inc.mk.
* BT_INCSDIR:                            bt.inc.mk.
* BT_INSTALL_BIN:                        Installation.
* BT_INSTALL_DATA:                       Installation.
* BT_INSTALL_DIR:                        Installation.
* BT_INSTALL_LIB:                        Installation.
* BT_INSTALL_SYMLINK:                    Installation.
* BT_LIB:                                bt.lib.mk.
* BT_LIB_MKPIC:                          bt.lib.mk.
* BT_LIB_MKSTATIC:                       bt.lib.mk.
* BT_LIBS:                               Program checking.
* BT_LIBS_LEX:                           Program checking.
* BT_MAN:                                bt.man.mk.
* BT_PKG_COMMENT:                        Definitions.
* BT_PKG_DISTFMTS:                       Definitions.
* BT_PKG_HOMEPAGE:                       Definitions.
* BT_PKG_LICENSE:                        Definitions.
* BT_PKG_MAINTAINER:                     Definitions.
* BT_PKG_NAME:                           Definitions.
* BT_PKG_VERSION:                        Definitions.
* BT_PREFIX:                             Definitions.
* BT_PROG:                               bt.prog.mk.
* BT_PROG_AWK:                           Program checking.
* BT_PROG_CC:                            Program checking.
* BT_PROG_CPP:                           Program checking.
* BT_PROG_CXX:                           Program checking.
* BT_PROG_INSTALLINFO:                   Program checking.
* BT_PROG_LD:                            Program checking.
* BT_PROG_LEX:                           Program checking.
* BT_PROG_MAKEINFO:                      Program checking.
* BT_PROG_MOC:                           qt.moc.mk.
* BT_PROG_SH:                            Program checking.
* BT_PROG_YACC:                          Program checking.
* BT_REQUIRE:                            Definitions.
* BT_SRCS <1>:                           bt.prog.mk.
* BT_SRCS:                               bt.lib.mk.
* MAKE_PRINT_VAR_ON_ERROR:               Variables.
* MAKEFLAGS:                             Variables.
* PWD:                                   Variables.
* QT_HDRS:                               qt.moc.mk.



Tag Table:
Node: Top243
Node: Introduction1539
Node: License3101
Node: Modules5012
Node: Comparisons6638
Ref: Comparisons-Footnote-18854
Node: Tutorial8927
Node: Unpacking9741
Ref: Unpacking-Footnote-110278
Node: Getting informed10390
Node: Configuring11437
Node: Making13432
Node: Site defaults14748
Node: Package structure15838
Node: Hierarchy16633
Node: Control files18246
Node: Top files19549
Node: Templates21044
Node: Definitions21649
Node: Configuration23292
Ref: Configuration-Footnote-124939
Node: Scripts24987
Node: Directories26292
Node: Features28072
Node: Variable types29339
Node: Checks31230
Node: Environment checking32049
Node: Program checking32600
Node: Header checking36034
Node: Library checking37600
Node: Miscellaneous checking39303
Node: Output41836
Node: Languages43707
Node: Subroutines44201
Node: pkgconfig46983
Node: pthread47593
Node: x1148757
Node: Makefiles49871
Node: Comments51227
Node: Dependancies51572
Node: Shell commands53332
Node: Variables54046
Node: File inclusion65797
Node: Conditionals67282
Node: Loops71338
Node: Special sources72045
Node: Special targets73911
Node: bt.prog.mk76631
Node: bt.lib.mk77339
Node: bt.man.mk78802
Node: bt.inc.mk79204
Node: qt.moc.mk79782
Node: Installation80921
Node: Documents81999
Node: Verification83076
Node: Distfiles84416
Node: Known formats86052
Node: Function index86903
Node: Variable index89034

End Tag Table
