[Home]Boost.Build Building Semantics

BOOST WIKI | RecentChanges | Preferences | Page List | Links List

Intent is to specify how features, toolsets, requirements and target type interact to generate updating actions. The proposal will leave user interface unchaged, but will provide more flexibility to handle new file types.

Let's assume the build process to have three major points.

  1. Global build request, specified by the user via BUILD variable.
  2. Build requests for each main target.
  3. Rules invocations that do actual job of specifying updating actions.

Remainder of this proposal specifies transitions between those points.

Computing build request for main targets

Suppose global build request was:
 gcc auc <runtime-link>static <doc-format>pdf
and src/main/Jamfile contains:
 exe main : main.cpp date.y date.l
The following steps will be performed:
  1. Global build request will be ``expanded'' to a set of build variants:
  2. Projects specific and target specific requirements are applied. This is performed as follows:

In this example, build variants will be:

 gcc <runtime-link>static <doc-format>pdf
 auc <runtime-link>static <doc-format>pdf

If src/dll_magic contains:

 requirements test/src/dll_magic : <runtime-link>dynamic
then nothing will be build in that subproject. (There are some hidden problems here, will document them later).

Generating build instruction for main targets

At this step set of build variants for main target is determined, and build instructions are to be generated. The following classification of targets is proposed:

Typed targets have the property that build instructions for them can be generated automatically. To allow this, each type has:

In our example case, description for type exe can be:
 { obj }
  { gcc.C++, toolset runtime-link, <toolset>gcc }
 { auc.C++, toolset, <toolset>auc } 
Suppose for an instant that we have this:
 exe main : main.obj ; 
So, target called main, of type 'exe' can be directly constructed. All the possible ways of doing so are found by:
  1. Computing cartesian product of build variants and generators.
  2. Removing pairs where generator preconditions are not satisfied.
  3. Removing from build request properties not relevant for a generator.
First step yeilds:
 gcc <runtime-link>static <doc-format>pdf,  { gcc.C++, ..., <toolset>gcc } 
 auc <runtime-link>static <doc-format>pdf,  { gcc.C++, ..., <toolset>gcc }
 gcc <runtime-link>static <doc-format>pdf, { auc.C++, ..., <toolset>auc } 
 auc <runtime-link>static <doc-format>pdf, { auc.C++, ..., <toolset>auc }
After second step we have:
 gcc <runtime-link>static <doc-format>pdf,  { gcc.C++, ..., <toolset>gcc }
 auc <runtime-link>static <doc-format>pdf, { auc.C++, ..., <toolset>auc } 
And the final result is:
 gcc <runtime-link>static,  { gcc.C++, ..., <toolset>gcc }
 auc, { auc.C++, ..., <toolset>auc }
Once build options are found, generators are invoked and are passed targets names as well as build variant selected.

However, in real life we'll have:

 exe main : main.cpp ; 
exe can't be directly constructed from cpp file, and ``intermediate targets'' are required. Algorithm is:
  1. Finding intermediate targets. For each type of source, a series of transformations from that type to the type of main target is found. If there's more than one, it is error. Intermediate targets of the path are created, named after source target. (Note: no two paths from source target to the main one intersect). (Note: how to call target that can be directly used to build the main target is to be decided.)
  2. Building intermediate targets. For each generator/build variant pair we compute build instructions for source using build variant. Note that properties not relevant to generator will be removed from build variant before intermediate target is processed.
  3. Placing intermediate targets. The build system insures that intermediate targets with different non-free properties are not mixed. Such checks are not performed for free properties. Eliminating free features altogether is not desirable, since:
    1. In that case target pathes would have to contain value of every property, including <include>, and that is very inconvenient.
    2. Unlike properties like toolset or debugging options, free properties change relatively unfrequently.
    For that reason, free properties for intermediate targets are tracked on subproject/main target basic. Namely:


 requirements test/src : <include>$(BOOST_PATH) ;

 exe t1 : t1.cpp common.cpp ;
 exe t2 : t2.cpp common.cpp ; 
 exe t3 : t3.cpp common.cpp : <define>MAGIC_SWITCH ;

Here, main targets t1 and t2 will use the same object file for common.cpp, while t3 will compile common.cpp for its use and store it separately.

[buy lipitor online] [buy lipitor] [[buy lipitor online]]

[buy fioricet online] [buy fioricet] [[buy fioricet online]]

BOOST WIKI | RecentChanges | Preferences | Page List | Links List
Edit text of this page | View other revisions
Last edited August 24, 2008 1:03 pm (diff)
Disclaimer: This site not officially maintained by Boost Developers