| Home | Libraries | People | FAQ | More

### Features and properties

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 for non-free features may not contain the '`<`', '`:`', or '`=`' characters. Feature values for free features may not contain the '`<`' character.

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 duplicates), 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

For free features, all values are valid. For all other features, the valid values are explicitly specified, and the build system will report an error for the use of an invalid feature-value. Subproperty validity may be restricted so that certain values are valid only in the presence of certain other subproperties. For example, it is possible to specify that the `<gcc-target>mingw` property is only valid in the presence of `<gcc-version>2.95.2`.

#### 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 an incidental property, for example, is one whose feature 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. [ where? ]

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

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

Features which are neither free nor incidental are called base features.

#### Feature Declaration

The low-level feature declaration interface is the `feature` rule from the `feature` module:

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

A feature's allowed-values may be extended with the `feature.extend` rule.

### Build Variants

A build variant, or (simply variant) is a special kind of composite feature which automatically incorporates the default values of features that . Typically you'll want at least two separate variants: one for debugging, and one for your release code. [ Volodya says: "Yea, we'd need to mention that it's a composite feature and describe how they are declared, in pacticular that default values of non-optional features are incorporated into build variant automagically. Also, do we wan't some variant inheritance/extension/templates. I don't remember how it works in V1, so can't document this for V2.". Will clean up soon -DWA ]

### 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 a specific combination of other properties. For example, one of compilers that you use issues a pointless 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. Conditional properties allow you to do just that. Their syntax is:

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

For example, the problem above would be solved by:

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

### Target identifiers and references

Target identifier is used to denote a target. The syntax is:

    target-id -> (project-id | target-name | file-name )
                  | (project-id | directory-name) "//" target-name
    project-id -> path
    target-name -> path
    file-name -> path
    directory-name -> path

This grammar allows some elements to be recognized as either

- project id (at this point, all project ids start with slash).
- name of target declared in current Jamfile (note that target names may include slash).
- a regular file, denoted by absolute name or name relative to project's sources location.

To determine the real meaning a check is made if project-id by the specified name exists, and then if main target of that name exists. For example, valid target ids might be:

    a                                    -- target in current project
    lib/b.cpp                            -- regular file
    /boost/thread                        -- project "/boost/thread"
    /home/ghost/build/lr_library//parser -- target in specific project

Rationale:Target is separated from project by special separator (not just slash), because:

- It emphasises that projects and targets are different things.
- It allows to have main target names with slashes.

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

For example,

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

would cause the version of `cmdline` library, optimized for space, to be linked in even if the `compiler` executable is build with optimization for speed.