boost.png (6897 bytes) Home Libraries People FAQ More
PrevUpHomeNext

Build process

Alternative selection
Determining common properties

The general overview of the build process was given in the user documentation. This section provides additional details, and some specific rules.

To recap, building a target with specific properties includes the following steps:

  1. applying default build,

  2. selecting the main target alternative to use,

  3. determining "common" properties

  4. building targets referred by the sources list and dependency properties

  5. adding the usage requirements produces when building dependencies to the "common" properties

  6. building the target using generators

  7. computing the usage requirements to be returned

Alternative selection

When there are several alternatives, one of them must be selected. The process is as follows:

  1. For each alternative condition is defined as the set of base properies in requirements. [Note: it might be better to specify the condition explicitly, as in conditional requirements].
  2. An alternative is viable only if all properties in condition are present in build request.
  3. If there's one viable alternative, it's choosen. Otherwise, an attempt is made to find one best alternative. An alternative a is better than another alternative b, iff set of properties in b's condition is strict subset of the set of properities of 'a's condition. If there's one viable alternative, which is better than all other, it's selected. Otherwise, an error is reported.

Determining common properties

The "common" properties is a somewhat artificial term. Those are the intermediate property set from which both the build request for dependencies and properties for building the target are derived.

Since default build and alternatives are already handled, we have only two inputs: build requests and requirements. Here are the rules about common properties.

  1. Non-free feature can have only one value

  2. A non-conditional property in requirement in always present in common properties.

  3. A property in build request is present in common properties, unless (2) tells otherwise.

  4. If either build request, or requirements (non-conditional or conditional) include an expandable property (either composite, or property with specified subfeature value), the behaviour is equivalent to explicitly adding all expanded properties to build request or requirements.

  5. If requirements include a conditional property, and condiiton of this property is true in context of common properties, then the conditional property should be in common properties as well.

  6. If no value for a feature is given by other rules here, it has default value in common properties.

Those rules are declarative, they don't specify how to compute the common properties. However, they provide enough information for the user. The important point is the handling of conditional requirements. The condition can be satisfied either by property in build request, by non-conditional requirements, or even by another conditional property. For example, the following example works as expected: 

exe a : a.cpp 
      : <toolset>gcc:<variant>release 
        <variant>release:<define>FOO ;
PrevUpHomeNext