Boost.Build v2 user manual

Tutorial

Hello, world

Properties

Project hierarchy

Using libraries

Static and shared libraries

Prebuilt targets

Reference documentation

Overview

Features and properties

Defintions

Property Validity

Feature Attributes

Feature Declaration

Build Variants

Subfeatures

Initialization

Command line

Projects

Targets

Build process

Installation

1. Place the Boost.Jam binary, called "bjam", somewhere in your PATH.
2. Specify the location of Boost.Build files. You can either set environmental variable BOOST_BUILD_PATH, or create, at the top of your project, a file called boost-build.jam, with a single line:

   boost-build /path/to/boost.build ;
   

   The directory "examples" in the distribution already has this file, so you can build projects there and add new without doing anything.

To verify your installation, you can use bjam --version at the command line.

Tutorial

Hello, world

   exe hello : hello.cpp ;

    bjam release 

   exe hello2 : hello.cpp ;

    bjam debug release

   bjam --clean debug release

   bjam hello2
   bjam --clean hello2

Properties

Boost.Build attempts to allow building different variants of projects, e.g. for debugging and release, or in single and multithreaded mode. In order to stay portable, it uses the concept of features, which is abstract aspect of build configuration. Property is just a (feature,value) pair. For example, there's a feature "debug-symbols", which can have a value of "on" or "off". When users asks to build project is a particual value, Boost.Build will automatically find the appropriate flags to the used compiler.

The "release" and "debug" in bjam invocation that we've seen are just are short form of specifying values of feature "variant". There is a lot of builtin features, and it's possible to write something like:

   bjam release inlining=off debug-symbols=on

   feature-name=feature-value

   exe hello 
       : hello.cpp
       : <include>/home/ghost/Work/boost <threading>multi

   project 
       : requirements <include>/home/ghost/Work/boost <threading>multi 
       ;

   exe hello : hello.cpp ;
   exe hello2 : hello.cpp ;

Project hierarchy

So far we only considered examples with one project (i.e. with one Jamfile). Typically, you'd have a lot of projects organized into a tree. At the top of the tree there's project root. This is a directory which contains, besides Jamfile, a file called "project-root.jam". Each other Jamfile has a single parent, which is the Jamfile in the nearest parent directory. For example, in the following directory layout:

    [top] 
      |
      |-- Jamfile
      |-- project-root.jam
      |
      |-- src
      |    |
      |    |-- Jamfile
      |    \-- app.cpp
      | 
      \-- lib
           |
           |-- lib1
           |    |
           |    |-- Jamfile
                |-- lib1.cpp

     <include>/home/ghost/local

    build-project src ;

Using libraries

     lib lib1 : lib1.cpp ;

     exe app : app.cpp ../lib/lib1/lib1 ;

    <optimization>full <cxxflags>-w-8080

    project 
        : usage-requirements <include>.
        ;

     lib lib1 : lib1.cpp ;

    project lib1
        : usage-requirements <include>.
        ;

    exe app : app.cpp @/lib1/lib1 ;

    use-project /lib1 : lib/lib1 ;

Static and shared libaries

Static libraries do not suffer from these problems, but considerably increase the size of application. Before describing static libraries, it's reasonable to give another, quite simple approach. If your project is built with <hardcode-dll-paths>true property, then the application will include the full paths for all shared libraries, eliminating the above problems. Unfortunately, you no longer can move shared library to a different location, which makes this option suitable only for debug builds. Further, only gcc compiler supports this option.

Building a library statically is easy. You'd need to change the value of <link> feature from it's deafault value shared, to static. So, to build everything as static libraries, you'd say

    bjam link=static

1. Suppose your library can be only build statically. This is easily achieved using requirements:

       lib l : l.cpp : <link>static ;
      
   

2. What if library can be both static and shared, but when using it in specific executable, you want it static? Target references are here to help:

       exe important : main.cpp helpers/<link>static ;
      
   

3. What if the library is defined in some other project, which you cannot change. But still, you want static linking to that library in all cases. You can use target references everywhere:

       exe e1 : e1.cpp @/other_project/lib1/<link>static ;
       exe e10 : e10.cpp @/other_project/lib1/<link>static ;
      
   

   but that's far from being convenient. Another way is to introduce a level of indirection: create a local target, which will refer to static version of lib1. Here's the solution:

       alias lib1 : @/other_project/lib1/<link>static ;
       exe e1 : e1.cpp lib1 ;
       exe e10 : e10.cpp lib1 ;
      
   

   (Note, that the "alias" target type is not yet implemented, but it's quite simple to do. I bet it's waiting for you to do it ;-))

Prebuilt targets

    lib lib2
       : 
       : <file>lib2_release.a <variant>release
       ;

    lib lib2
       : 
       : <file>lib2_debug.a <variant>debug
       ;

    exe app : app.cpp @/lib/lib1/lib2 ../lib/lib2/lib2 ;

    lib zlib : : <name>z ;

    lib zlib : : <name>z <search>/opt/lib ;

    lib zlib : : <name>z <variant>release ;
    lib zlib : : <name>z_d <variant>debug ;

Reference

Overview

The most fundemental entity in Boost.Build is main target. This is object that user want to construct from sources and keep up to date with regard to those sources. Typical examples of main targets are executable files and libraries.

Main targets are grouped in projects. Their main purpose is organization: related targets placed in one project, can then be built together, or share some definitions.

Main targets and projects are described mostly in declarative fashion. (TODO: what "declarative fashion" means to a user?) To make some use of them, user issues build request, which specifies what targets user wants to build, and what properties are desirable. Build request is not necessary explicit. Invoking the build system without parameters will build the project in current directory with default properties.

The properties describe various aspects of constructed objects. For portability, they are specified in a normalized form, for example

<optimization>full <inlining>off

Construction of each main target begins with finding properties for this main target. They are found by processing both build request, and target requirements, which give properties needed for the target to build. For example, a given main target might require certian defines, or will not work unless compiled in multithreaded mode. The process of finding properties for main target is described in property refinement.

After that, dependencies (i.e. other main targets) are build recursively. Build request for dependencies is not always equal to those of dependent — certain properties are dropped and user can explicitly specify desired properties for dependencies. See propagated features and target reference for details.

When dependencies are constructed, the dependency graph for this main target and for this property set is created, which describes which files need to be created, on which other files they depend and what actions are needed to construct those files. There's more that one method, and user can define new ones, but usually, this involves generators and target types.

Target type is just a way to classify targets. For example, there are builtin types EXE, OBJ and CPP. Generators are objects that know how to convert between different target type. When a target of a given type must be created, all generators for that type, which can handle needed properties, are found. Each is passed the list of sources, and either fails, or returns a dependency graph. If a generator cannot produce desired type from given sources, it may try to recursively construct types that it can handle from the types is was passed. This allows to try all possible transformations. When all generators are tried, a dependency graph is selected.

Finally, the dependency graph is passed to underlying Boost.Jam program, which runs all actions needed to bring all main targets up-to date. At this step, implicit dependencies are also scanned and accounted for, as described here.

Features and properties

Definitions

A feature is a normalized (toolset-independent) aspect of a build configuration, such as whether inlining is enabled. Feature names may not contain the '>' character.

Each feature in a build configuration has one or more associated values. Feature values may not contain the '<', ':', or '=' characters.

A property is a (feature,value) pair, expressed as <feature>value.

A subfeature is a feature which only exists in the presence of its parent feature, and whose identity can be derived (in the context of its parent) from its value. A subfeature's parent can never be another subfeature. Thus, features and their subfeatures form a two-level hierarchy.

A value-string for a feature F is a string of the form value-subvalue1-subvalue2...-subvalueN, where value is a legal value for F and subvalue1...subvalueN are legal values of some of F's subfeatures. For example, the properties <toolset>gcc <toolset-version>3.0.1 can be expressed more conscisely using a value-string, as <toolset>gcc-3.0.1.

A property set is a set of properties (i.e. a collection without dublicates), for instance: <toolset>gcc <runtime-link>static.

A property path is a property set whose elements have been joined into a single string separated by slashes. A property path representation of the previous example would be <toolset>gcc/<runtime-link>static.

A build specification is a property set which fully describes the set of features used to build a target.

Property Validity

Feature Attributes

Each feature has a collection of zero or more of the following attributes. Feature attributes are low-level descriptions of how the build system should interpret a feature's values when they appear in a build request. We also refer to the attributes of properties, so that a incidental property, for example, is one whose feature is has the incidental attribute.

• incidental

  Incidental features are assumed not to affect build products at all. As a consequence, the build system may use the same file for targets whose build specification differs only in incidental features. A feature which controls a compiler's warning level is one example of a likely incidental feature.

  Non-incidental features are assumed to affect build products, so the files for targets whose build specification differs in non-incidental features are placed in different directories as described in target paths below.

• propagated

  Features of this kind are propagated to dependencies. That is, if a main target is built using a propagated property, the build systems attempts to use the same property when building any of its dependencies as part of that main target. For instance, when an optimized exectuable is requested, one usually wants it to be linked with optimized libraries. Thus, the <optimization> feature is propagated.

• free

  Most features have a finite set of allowed values, and can only take on a single value from that set in a given build specification. Free features, on the other hand, can have several values at a time and each value can be an arbitrary string. For example, it is possible to have several preprocessor symbols defined simultaneously:

  <define>NDEBUG=1 <define>HAS_CONFIG_H=1
  

  
  
• optional

  An optional feature is a feature which is not required to appear in a build specification. Every non-optional non-free feature has a default value which is used when a value for the feature is not otherwise specified, either in a target's requirements or in the user's build request. [A feature's default value is given by the first value listed in the feature's declaration. -- move this elsewhere - dwa]

• symmetric

  A symmetric feature's default value is not automatically included in build variants. Normally a feature only generates a subvariant directory when its value differs from the value specified by the build variant, leading to an assymmetric subvariant directory structure for certain values of the feature. A symmetric feature, when relevant to the toolset, always generates a corresponding subvariant directory.

• path

  The value of a path feature specifies a path. The path is treated as relative to the directory of Jamfile where path feature is used and is translated appropriately by the build system when the build is invoked from a different directory

• implicit

  Values of implicit features alone identify the feature. For example, a user is not required to write "<toolset>gcc", but can simply write "gcc". Implicit feature names also don't appear in variant paths, although the values do. Thus: bin/gcc/... as opposed to bin/toolset-gcc/.... There should typically be only a few such features, to avoid possible name clashes.

• composite

  Composite features actually correspond to groups of properties. For example, a build variant is a composite feature. When generating targets from a set of build properties, composite features are recursively expanded and added to the build property set, so rules can find them if neccessary. Non-composite non-free features override components of composite features in a build property set.

• link-incompatible

  See below.

• dependency

  The value of dependency feature if a target reference. When used for building of a main target, the value of dependency feature is treated as additional dependency.

  For example, dependency features allow to state that library A depends on library B. As the result, whenever an application will link to A, it will also link to B. Specifying B as dependency of A is different from adding B to the sources of A.

TODO: document active features..

Feature Declaration

rule feature ( name : allowed-values * : attributes * )

Build Variants

Link compatible and incompatible properties

When the build system tries to generate a target (such as library dependency) matching a given build request, it may find that an exact match isn't possible — for example, the target may impose additonal build requirements. We need to determine whether a buildable version of that target can actually be used.

The build request can originate in many ways: It may come directly from the user's command-line, from a dependency of a main target upon a library, or from a dependency of a target upon an executable used to build that target, for example. For each way, there are different rules whether we can use a given subvariant or not. However we currently only assume linking and therefore use a simple approach described in the following paragraph.

In general, there are many possible situations: a libary which is dependency of a main target and should be linked into it, target which is directly requested on the command line, or build executable which is used in the build process itself. At this moment we use a simple approach.

Two property sets are called link-compatible when targets with those property sets can be used interchangably. In turn, two property sets are link compatible when there's no link-incompatible feature which has different values in those property sets. Whenever requested and actual properties are link-compatible, it's OK. Otherwise, it's an error.

Definition of property refinement

When a target with certain properties is requested, and that target requires some set of properties, it is needed to find the set of properties to use for building. This process is called property refinement and is performed by these rules

1. If original properties and required properties are not link-compatible, refinement fails.
2. Each property in the required set is added to the original property set
3. If the original property set includes property with a different value of non free feature, that property is removed.

Conditional properties

Sometime it's desirable to apply certain requirements only for specific combination of other properties. For example, one of compilers that you use issues a poinless warning that you want to suppress by passing a command line option to it. You would not want to pass that option to other compilers. Condititional properties allow to do that. Their systax is:

  property ( "," property ) * ":" property

exe hello : hello.cpp : <toolset>yfc:<cxxflags>-disable-pointless-warning ;

Initialization

bjam's first job upon startup is to load the Jam code which implements the build system. To do this, it searches for a file called "boost-build.jam", first in the invocation directory, then in its parent and so forth up to the filesystem root, and finally in the directories specified by the environment variable BOOST_BUILD_PATH. When found, the file is interpreted, and should specify the build system location by calling the boost-build rule:

      rule boost-build ( location ? )

     boost-build build-system ;

The default "bootstrap.jam", after loading some standard definitions, loads two files, which can be provided/customised by user: "site-config.jam" and "user-config.jam".

Locations where those files a search are summarized below:

Command line

The comamnd line may contain:

• Jam options,
• Boost.Build options,
• Command line arguments

Command line arguments

• An argument which does not contain slashes or the "=" symbol is either a value of an implicit feature, or target to be built. It is taken to be value of a feature if appropriate feature exists. Otherwise, it is considered a target id. Special target name "clean" has the same effect as "--clean" option.
• An argument with either slashes or the "=" symbol specifies a number of build request elements. In the simplest form, it's just a set of properties, separated by slashes, which become a single build request element, for example:

  borland/<runtime-link>static
  

  More complex form is used to save typing. For example, instead of

  borland/runtime-link=static borland/runtime-link=dynamic
  

  one can use

  borland/runtime-link=static,dynamic
  

  Exactly, the conversion from argument to build request elements is performed by (1) splitting the argument at each slash, (2) converting each split part into a set of properties and (3) taking all possible combination of the property sets. Each split part should have the either the form

      feature-name=feature-value1[","feature-valueN]*   
  

  or, in case of implict feature

      feature-value1[","feature-valueN;]*   
  

  and will be converted into property set

  <feature-name>feature-value1 .... <feature-name>feature-valueN
  

    target1 debug gcc/runtime-link=dynamic,static
   

Command line options

All of the Boost.Build options start with the "--" prefix. They are described in the following table.

Projects

Boost.Build considers every software it build as organized into projects, each of which corresponds to a single Jamfile. Projects are organized in a hierarchical structure, so each project may have a single parent project and a number of subprojects.

Each project is also associated with project root. That's a root for a tree of projects, which specifies some global properties.

Project root

• configure toolsets, via call to toolset.using
• refer to other projects, via the use-project rule
• declare constants, via the constant and path-constant rules.

Project attributes

For each project, there are several attributes.

Project id is a short way to denote a project, as opposed to the Jamfile's pathname. It is a hierarchical path, unrelated to filesystem, such as "boost/thread". Target references make use of project ids to specify a target.

Source location specifies the directory where sources for the project are located.

Project requirements are requirements that apply to all the targets in the projects as well as all subprojects.

Default build is the build request that should be used when no build request is specified explicitly.

The default values for those attributes are given in the table below. In order to affect them, Jamfile may call the project rule. The rule has this syntax:

    project id : <attributes> ;
   

    project tennis 
        : requirements <threading>multi 
        : default-build release
        ;
   

Project relationship

There are three kinds of project relationships.

First is parent-child. This relationship is established implicitly: parent directories of a project are searched, and the first found Jamfile is assumed to define the parent project. The parent-child relationship affects only attribute values for the child project.

Second is build relationship. Some project may request to recursively build other projects. Those project need not be child projects. The build-project rule is used for that:

    build-project src ;   

The third kind is the 'use' relationship. In means that one project uses targets from another. It is possible to just refer to target in other projects using target id. However, if target id uses project id, it is required that the project id is known. The use-project rule is employed to guarantee that.

    use-project ( id : location )
   

Targets

There are two user-visible kinds of targets in Boost.Build. First are "abstract" — they correspond to things declared by user, for example, projects and executable files. The primary thing about abstract target is that it's possible to request them to be build with a particular values of some properties. Each combination of properties may possible yield different set of real file, so abstract target do not have a direct correspondence with files.

File targets, on the contary, are associated with concrete files. Dependency graphs for abstract targets with specific properties are constructed from file targets. User has no was to create file targets, however it can specify rules that detect file type for sources, and also rules for transforming between file targets of different types. That information is used in constructing dependency graph, as desribed in the next section. Note:File targets are not the same as targets in Jam sense; the latter are created from file targets at the latest possible moment. Note:"File target" is a proposed name for what we call virtual targets. It it more understandable by users, but has one problem: virtual targets can potentially be "phony", and not correspond to any file.

Main targets and main target alternatives

Main target is a named entity which can be build, for example a named executable file. To declare a main target, user invokes some of the main target rules, passing it things like list of sources and requirements.

It is possible to have different list of sources for different toolsets, therefore it is possible to invoke main target rules several times for a single main target. For example:

    exe a : a_gcc.cpp : <toolset> ;
    exe a : a.cpp ;

Target identifiers and references

Target identifier is used to denote a target. It is described by the following grammar:

    target-id -> project-reference local-target-name
    project-reference -> [jamfile-location] [ "@" [project-id] ]
    jamfile-location -> pathname 
    project-id -> pathname
    local-target-name -> identifier

    a
    lib/b
    @/boost/thread
    /home/ghost/build/lr_library@parser/lalr1

1. If project-reference is empty, then the current project is used — i.e. the project there the target id occurs.
2. If the project id is absolute, the project with that id is used.
3. If the project id is relative, it is treated relatively to project-id of the project at jamfile-location. If that project does not declare project id, it is an error.

Target reference is used to specify a source target, and may additionally specify desired properties for that target. It has this syntax:

    target-reference -> target-id [ "/" requested-properties ]
    requested-properties -> property-path

    exe compiler : compiler.cpp libs/cmdline/<optimization>space ;

Ambiguity resolution

Target reference may have the same form as a pathname, for example lib/a. In order to determine if this is target reference or pathname, it is checked if there's a jamfile in the specified path. If there is one, it is loaded and if the specified target is declared by that project it is used. Otherwise, we just treat the target reference as a file name.

File targets

Types

Target paths

To distinguish targets build with different properties, they are put in different directories. Rules for determining target paths are given below:

1. All targets are placed under directory corresponding to the project where they are defined.
2. Each non free, non incidental property cause an additional element to be added to the target path. That element has the form <feature-name>-<feature-value> for ordinary features and <feature-value> for implicit ones. [Note about composite features].
3. If the set of free, non incidental properties is different from the set of free, non incidental properties for the project in which the main target that uses the target is defined, a part of the form main_target-<name> is added to the target path. Note:It would be nice to completely track free features also, but this appears to be complex and not extremely needed.

For example, we might have these paths:

    debug/optimization-off
    debug/main-target-a
   

Build request

Build process

Given a list of targets ids and a build request, building goes this way. First, for each id we obtain the abstract targets corresponding to it. This also loads all necessary projects. If no target id is given, project in the current directory is used. Build request is expanded, and for each resulting property set, the generate method of all targets is called, which yields a list of virtual targets. After that all virtual targets are actualized, and target "all" is set to depend on all created actual targets. Lastly, depending on whether --clean option was given, either target "all" or target "clean" is updated. Generation of virtual target from abstract one is performed as follows:

• For project targets, all of main targets are generated with the same properties. Then all projects referred via "build-project" are generated as well. If it's not possible to refine requested properties with project requirements, the project is skipped.
• For main target, steps are:
  1. All main target alternatives which requirements are satisfied by the build request are enumerated.
  2. If there are several such alternatives, the one which longer requirements list is selected.
• For each selected alternative
  1. Each target reference in the source list are recursively constructed.
  2. Properties are refined with alternative's requirements, and active features in the resulting set are executed.
  3. Conditional properties are evaluated.
  4. The dependency graph for the target is constructed in a way which depends on the kind of main target, typically using generators.

Generators

To construct a main target with given properties from sources, it is required to create a dependency graph for that main target, which will also include actions to be run. The algorithm for creating the dependency graph is described here.

The fundamental concept is generator. If encapsulates the notion of build tool and is capable to converting a set of input targets into a set of output targets, with some properties. Generator matches a build tool as closely as possible: it works only when the tool can work with requested properties (for example, msvc compiler can't work when requested toolset is gcc), and should produce exactly the same targets as the tool (for example, if Borland's linker produces additional files with debug information, generator should also).

Given a set of generators, the fundamental operation is to construct a target of a given type, with given properties, from a set of targets. That operation is performed by rule generators.construct and the used algorithm is described below.

Selecting and ranking viable generators

Each generator, in addition to target types that it can produce, have attribute that affects its applicability in particular sitiation. Those attributes are:

1. Required properties, which are properties absolutely necessary for the generator to work. For example, generator encapsulating the gcc compiler would have <toolset>gcc as required property.
2. Optional properties, which increase the generators suitability for a particual build.

When trying to construct a target, the first step is to select all possible generators for the requested target type, which required properties are a subset of requested properties. Generators which were already selected up the call stack are excluded. In addition, if any composing generators were selected up the call stack, all other composing generators are ignored (TODO: define composing generators). The found generators assigned a rank, which is the number of optional properties present in requested properties. Finally, generators with highest rank are selected for futher processing.

Running generators

When generators are selected, each is run to produce a list of created targets. This list might include targets which are not of requested types, because generators create the same targets as some tool, and tool's behaviour is fixed. (Note: should specify that in some cases we actually want extra targets). If generator fails, it returns an empty list. Generator is free to call 'construct' again, to convert sources to the types it can handle. It also can pass modified properties to 'constuct'. However, a generator is not allowed to modify any propagated properties, otherwise when actually consuming properties we might discover that the set of propagated properties is different from what was used for building sources.

For all targets which are not of requested types, we try to convert them to requested type, using a second call to construct. This is done in order to support transformation sequences where single source file expands to several later. See this message for details.

Selecting dependency graph

Property adjustment

Because target location is determined by the build system, it is sometimes necessary to adjust properties, in order to not break actions. For example, if there's an action which generates a header, say "a_parser.h", and a source file "a.cpp" which includes that file, we must make everything work as if a_parser.h is generated in the same directory where it would be generated without any subvariants.

Correct property adjustment can be done only after all targets are created, so the approach taken is:

1. When dependency graph is constructed, each action can be assigned a rule for property adjustment.
2. When virtual target is actualized, that rule is run and return the final set of properties. At this stage it can use information of all created virtual targets.

In case of quoted includes, no adjustment can give 100% correct results. If target dirs are not changed by build system, quoted includes are searched in "." and then in include path, while angle includes are searched only in include path. When target dirs are changed, we'd want to make quoted includes to be search in "." then in additional dirs and then in the include path and make angle includes be searched in include path, probably with additional paths added at some position. Unless, include path already has "." as the first element, this is not possible. So, either generated headers should not be included with quotes, or first element of include path should be ".", which essentially erases the difference between quoted and angle includes. Note: there only way to get "." as include path into compiler command line is via verbatim compiler option. In all other case, Boost.Build will convert "." into directory where it occurs.

Transformations cache

Dependency scanning

Dependency scanning is the process of finding implicit dependencies due to "include" statements and similar things. It has to take into account two things:

• Whether includes in a particular file need to be taken into account depends on actions that use that file. For example, if the action is "copy file", then includes should be ignored. Another example is when a file is compiled with two different include paths on different toolsets.
• It is possible to include generated header. In which case, it may not yet exist at the time when we scan dependencies.

Dependency scanning is implemented by objects called scanners. See documentation for the "scanner" module to detail.

Regarding the first problem, we really have no choice. We can't treat the same actual target differently depending on from where it is used. Therefore, when handling of includes differers depending on actions, we have to duplicate targets and assign different properties to it.

For the reason, when actualizing a virtual target we optionally pass the needed scanner to the "virtual-target.actualize" method. When no scanner is passed, a new actual target is created, with it's dependencies and updating actions set accordingly. When a particular scanner is specified, a new actual target is created. That target will depend on target created without scanner. In effect, this will allow to use different scanners for the same file.

Generated headers

1. If there's such file there, or
2. If there's a target of the same name, bound to that dir via LOCATE_TARGET.

    INCLUDES $(<) : [ SEARCH_FOR_TARGET $(>) : $(SEARCH_PATH) ] ;

     "/usr/include" "/home/t" "."

     "/usr/include" "/home/t" "." "build"

1. File "a.cpp" will be correctly compiled. Note that it's already necessary to adjust paths to ensure this. We'll have to add target paths for all generated headers, because determining the exact set of additional include path for each source -- i.e the set of headers that it uses --- will be hard.
2. With the proposed SEARCH_FOR_TARGET rule, dependency on generated header will work magically --- it would find the "a_parser.h" target bound via LOCATE_TARGET to "build" and we'll call INCLUDE on that found target, instread of creating a completely unrelated one.

Last modified: Oct 10, 2002

© Copyright Vladimir Prus 2002. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies. This document is provided ``as is'' without express or implied warranty, and with no claim as to its suitability for any purpose.