Chapter 11. Build scripts

Table of Contents

11.1. Makefile syntax
11.1.1. Comments
11.1.2. File dependancy specification
11.1.3. Running shell commands
11.1.4. Variable assignments
11.1.5. Makefile inclusion
11.1.6. Conditionals
11.1.7. Loops
11.1.8. Special sources
11.1.9. Special targets
11.2. Standard makefile modules
11.2.1. Directory recursion
11.2.2. Building programs
11.2.3. Building libraries
11.2.4. Cleaning files
11.2.5. Generating dependancy information
11.2.6. Header files
11.2.7. Manual pages
11.2.8. TeXinfo documentation
11.2.9. QT moc file generation
11.3. Manual file installation

Warning

The bt_make module will be deprecated soon; you are encouraged to avoid using it. It has been superseded by bt_logic; use this one and report your feelings to get a better program.

The build process of a source package is controlled by several build scripts, also called makefiles. A build script defines several targets and tracks dependancies between files that need to be generated. There is a script inside each directory, and each one does exactly a single task. Lets repeat this, as it is an important concept: each script does a single and unique task. Some important standard tasks are:

Note that you can add new tasks if needed by writing your own custom scripts. Each task shown above has its set of targets associated. Targets are standard and should not be extended to avoid confusion. See Chapter 5, Building targets for a description of the ones available.

The build script file is always named Makefile.bt to avoid conflicts with the regular make utility. They are parsed by the bt_make module[13].

Build scripts will usually have the following structure:

.include "../bt_config.mk"

# Variable definitions that tune details of makefile modules.

# Inclusion of some makefile modules.

The inclusion of the configuration makefile, bt_config.mk, is optional (it is pulled in automatically by Buildtool later) but needed in some cases (when you need conditionals or loops). To be safe it is suggested that you always include it manually.

11.1. Makefile syntax

The following subsections describe the syntax used in makefiles.[14].

11.1.1. 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.

11.1.2. 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.

11.1.3. Running 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.

11.1.4. 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.

.PARSEDIR

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 will not 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.

11.1.5. Makefile 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.

11.1.6. 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, 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 (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.

11.1.7. 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.

11.1.8. Special sources

There are some special source specifications that you may add to your dependancy lines:

.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.

11.1.9. 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.

11.2. Standard makefile modules

This section describes all standard makefile modules, useful to simplify your own makefiles a lot. Use them whenever possible, as they will provide consistency across packages.

The bt.init.mk makefile module contains lots of code that must be present in all makefiles. It defines the default targets, some important variables, includes the configuration makefile, etc. You do not have to include this file manually in your scripts if and only if you use any of the makefile modules described below. If you are creating your own makefile for a specific task, then you must include this file by hand.

11.2.1. Directory recursion

Directory recursion is used to build the same target in multiple directories at once. It is always used in the top level makefile of your project to enter, at least, the directory containing your sources. This functionality is provided by the bt.subdir.mk makefile.

The BT_SUBDIR variable contains a whitespace separated list of directories that should be recursed. No other variables are important here, as you cannot do any other job if the makefile recurses into directories (remember, a task per script).

As an example, the following is the standard Makefile.bt you could use in your top level directory:

BT_SUBDIR= src

.include <bt.subdir.mk>

11.2.2. Building programs

Programs are built using the bt.prog.mk makefile module. This takes care to generate dependancy information, build object files, link the program, install it in place and clean all temporary files when requested.

The following variables are recognized:

BT_MAN

Whitespace separated list of manual pages related to the program. If not defined, its default value is ${BT_PROG}.1.

BT_PROG

The name of the final binary program.

BT_SRCS

Whitespace separated list of source files. If not defined, its default value is ${BT_PROG}.c.

A simple example:

BT_PROG= testprogram
BT_SRCS= main.c compat.c
BT_MAN= testprogram.8

.include <bt.prog.mk>

This module automatically pulls in bt.clean.mk (see Section 11.2.4, “Cleaning files”), bt.dep.mk (see Section 11.2.5, “Generating dependancy information”) and bt.man.mk (see Section 11.2.7, “Manual pages”). Therefore, their functionality is available in the build script too.

11.2.3. Building libraries

Libraries are built using the bt.lib.mk makefile module. This takes care to generate dependancy information, build object files, link the library, install it in place and clean all temporary files when requested.

Generated libraries may be either static and dynamic, static only or dynamic only, depending on what the configuration stage detected. These are internal details to the makefile and Buildtool, so you should not worry about them at all when writing your build script.

The following variables are recognized:

BT_LIB

The base name of the library. Contains no extension nor the lib prefix.

BT_LIB_MAJOR

The major version number. This is required.

BT_LIB_MINOR

The minor version number. This is optional.

BT_LIB_MICRO

The micro version number. This is optional, and only applicable if BT_LIB_MINOR is defined.

BT_LIB_MKPIC

If set to no, disable shared library building, even if it was enabled during the configuration stage. This is useful for convencience archives.

BT_LIB_MKSTATIC

If set to yes, force build of a static archive, even if it was disabled during the configuration stage. This is useful for convencience archives.

BT_MAN

Whitespace separated list of manual pages related to the library, if any.

BT_SRCS

Whitespace separated list of source files. If not defined, its default value is ${BT_LIB}.c.

A simple example:

BT_LIB= testlib
BT_LIB_MAJOR= 1
BT_LIB_MINOR= 0

BT_SRCS= func1.c func2.c func3.c

.include <bt.lib.mk>

This module automatically pulls in bt.clean.mk (see Section 11.2.4, “Cleaning files”), bt.dep.mk (see Section 11.2.5, “Generating dependancy information”) and bt.man.mk (see Section 11.2.7, “Manual pages”). Therefore, their functionality is available in the build script too.

11.2.4. Cleaning files

The bt.clean.mk makefile module provides functionality to remove files during the clean and cleandir targets.

The following variables are recognized:

BT_FILES_CLEAN

Whitespace separated list of files that have to be removed during the clean target.

BT_FILES_CLEANDIR

Whitespace separated list of files that have to be removed during the cleandir target.

11.2.5. Generating dependancy information

Almost all C and C++ source code include some header files. These are dependancies in the sense that if they change, object files need to be rebuilt. The bt.dep.mk makefile module automatically extracts this information and lets bt_make track dependancies appropiately.

This module works transparently, as it takes the source file list from the BT_SRCS variable, always defined when building libraries or programs.

If you need to extract dependancy information from some additional file that is not present in the BT_SRCS variable, you can add it to the BT_DEPSRCS variable.

11.2.6. Header files

Libraries usually include header files that need to be installed in the system together with the library, so that third-party programs can use it. This can be done using the bt.inc.mk makefile module.

The following variables are recognized:

BT_INCS_INSTALL

If set to no, do not install header files.

BT_INCS

Whitespace separated list of header files that have to be installed.

BT_INCSDIR

Installation directory for header files.

BT_INCSDIR_<header_name>

This lets you define the installation directory for header files on a file basis, avoiding the default BT_INCSDIR directory.

BT_INCSNAME_<header_name>

This lets you define the installation file name for header files on a file basis, avoiding the default BT_INCSDIR directory.

A simple example:

BT_INCS= testlibrary.h func1.h func2.h
BT_INCSDIR= ${BT_DIR_INCLUDE}/testlibrary
BT_INCSDIR_testlibrary.h= ${BT_DIR_INCLUDE}

.include <bt.inc.mk>

11.2.7. Manual pages

Manual pages are handled by the bt.man.mk makefile module. They are only installed, not built[15].

The only variable provided by this module is BT_MAN, which contains a whitespace separated list of manual page filenames that need to be installed. It will take care to place them in the right section, according to filename extensions.

A simple example:

BT_MAN= func1.3 func2.3 testprogram.1

.include <bt.man.mk>

11.2.8. TeXinfo documentation

TeXinfo documentation is handled by the bt.info.mk makefile module. This takes care to generate GNU Info files and install them in place, updating the GNU Info directory to add the new document.

The following variables are recognized:

BT_INFO_INSTALL

If set to no, do not install GNU Info files, only build them.

BT_TEXINFO

Whitespace separated list of TeXinfo files to be handled.

11.2.9. QT 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). The qt.moc.mk makefile module will help you to do this.

This makefile module uses the moc preprocessor, so you must detect it from your configuration file using the following check:

bt_check_progs BT_PROG_MOC "moc"

The QT_HDRS variable is the only one recognized by this file. It includes a whitespace separated list of C++ header files that have to be parsed using the preprocessor.

Note that this makefile must be included before any standard Buildtool makefile. A simple 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>

11.3. Manual file installation

You will probably need to install some files manually, the ones that cannot be handled by standard makefile modules (i.e., configuration files). To aid you in this task, there are several useful variables that contain the right command to install files. This section describes them.

Note

For these variables to work, bt.init.mk must be included in your makefile. All standard makefile modules (see Section 11.2, “Standard makefile modules”) include it by default.

To create directories, there is the BT_INSTALL_DIR command. All arguments given to it will be treated as directories that need to be created in the system.

To install files, there are several commands available. All of them are used in the same way, though the premissions of the target file will be different depending on the nature of the command. If two arguments are given, the first one is treated as the source file while the second one can be either the name of a directory (and the original name is kept) or the name of the target file (so it is renamed). If more than two arguments are given, all of them are treated as source files, except the last one which must be the target directory. The commands are: BT_INSTALL_BIN and BT_INSTALL_DATA, BT_INSTALL_LIB. The utility invoked by these commands tries to be compatible with the BSD install utility (with respect to semantics).

To install symbolic links, there is the BT_INSTALL_SYMLINK command. The first argument is treated as the source name while the second one is the target name.

Warning

You should not, in any case, install files using any other command like cp or tar. The reason is that the use of the directives shown above let Buildtool know which files are beeing installed. In a future, these may be registered in a file list to allow package deinstallation or to handle conflicting files.



[13] Which is a slightly modified version of NetBSD's make utility.

[14] Most of this text has been taken verbatim from NetBSD's make's manual page.

[15] This might change in the future, though building manual pages may be a bit problematic.