Boost.Build Building Semantics

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

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

 exe main : main.cpp date.y date.l

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:

• if next requirement contains non-free property not present in a build variant, that variant will be skipped. This can result in suproject been completely skipped
• free properties from requirements are added to all build variants.

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

Generating build instruction for main targets

• untyped -- build system cannot automatically generate build instructions for it
• typed
  • main
  • intermediate
    • main target specific
    • subproject specific

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

• set of other types which can be used in building
• set of generators, where each generator is:
  • rule that should be invoked to generate build instructions
  • features that are relevant to the rule
  • preconditions: properties that must be set in order to invoke the rule

 { obj }
 { 
  { gcc.C++, toolset runtime-link, <toolset>gcc }
 { auc.C++, toolset, <toolset>auc } 
 }

 exe main : main.obj ; 

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.

 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 }

 gcc <runtime-link>static <doc-format>pdf,  { gcc.C++, ..., <toolset>gcc }
 auc <runtime-link>static <doc-format>pdf, { auc.C++, ..., <toolset>auc } 

 gcc <runtime-link>static,  { gcc.C++, ..., <toolset>gcc }
 auc, { auc.C++, ..., <toolset>auc }

However, in real life we'll have:

 exe main : main.cpp ; 

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:
   • If intermediate targets' main target has no explicit requirements, intermediate target is called ``subproject specific'' and will be stored under $(SUBPROJECT_TARGET_DIR)/bin/subproject-specific/....
   • If main target has explicit requirements, intermediate target is called ``target specific''. It is considered to be link-uncompatible with subproject specific intermediate targets as well as with those belonging to other main targets.

Example:

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