Using *BUILT and *MADE OF Implicit States

A typical build configuration is:

- A compiler build tool which produces one item of type OBJECT from one input of type SOURCE; and

- A linker build tool which produces one output item of type EXE from several inputs of type OBJECT.

Typically, there are other inputs in addition to these. But by considering this simple example of a configuration involving just three item types, it will become apparent how *BUILT and *MADE OF can be used in any configuration.

For other rules that use implicit states, see Rules Using Implicit States.

Example 1

A suitable baseline template would be:

EXE | *BUILT
OBJECT | *BUILT
SOURCE | *MADE OF

NOTE The order in which template rules are specified makes no difference to the content of a baseline.

The effect of this template is:

- First, because *BUILT processing comes at the end, to include in the baseline SOURCE item revisions at the *FINAL (i.e. final normal) state.

- Then, to include those OBJECT item revisions which were built (compiled) from the SOURCE revisions already included.

- Finally, to include any EXE item revisiona built (linked) from some combination of these included OBJECT revisions.

There must be a specified rule (or the default rule) to cover each stage in the build process. If the rule for OBJECT had been omitted, then the rule for EXE could not have included anything because none of the build inputs for any EXE item would be present.

Example 2

Another suitable baseline template would be:

EXE | *HIGHEST
OBJECT | *MADE OF
SOURCE | *MADE OF

NOTE The rules could be given in any order.

The effect of this template is:

- First, because *MADE OF processing comes at the end, to include in the baseline all the EXE items, choosing the revisions at the *HIGHEST state, for example, the best revision available for each EXE item.

- Then, to include those revisions of OBJECT items which were used to build the revision of each EXE item already included, unless it is found that two or more different revisions of the same OBJECT item were used in building those EXE items (the EXE rule would have to have included at least two different items for such a conflict to possibly arise). If such a conflict is found, it is flagged and reported, and no revision of that OBJECT item is included.

- Then, to include the SOURCE item revisions which were used to build each OBJECT item revision already included (and therefore not flagged) – which, provided that there is a one-to-one correspondence between SOURCE and OBJECT items, will not result in any further conflicts being found.

There must be a specified rule (or the default rule) to cover each stage in the build process. If the rule for OBJECT had been omitted, then the rule for SOURCE could not have included anything because the SOURCE items do not themselves belong to the made-of list of any EXE item. Although an EXE item is built ultimately from SOURCE items, this requires made-of lists to be used in combination.

Example 3

Another example of how revision conflicts could arise would be in the following template:

OBJECT | *LATEST
SOURCE | *MADE OF
ENV | *MADE OF

Here, ENV items are environment items, some of which may be used in the build compilations of several different OBJECT items. Different revisions of one ENV item might have been used in the compilations which produced the OBJECT items already included.

Example 4

It is valid to have a template with both *BUILT and *MADE OF rules, such as:

EXE | *BUILT
OBJECT | *LATEST
SOURCE | *Revision that makes selected outputs

It is necessary that the other rules in such a template include items which are in between in the build process. This means that the rules for *BUILT inclusion and those for *MADE OF inclusion will never conflict with each other. In this example OBJECT items have been included first, followed by both the EXE revisions built from them and the SOURCE revisions used to build them.

Example 5

It is not valid to have a template consisting solely of *BUILT and/or *MADE OF rules. For example:

OBJECT | *BUILT
SOURCE | *MADE OF

Such a template would include nothing because there is nothing selected to start off with. Neither the *BUILT nor the *MADE OF processing could possibly find anything to qualify for inclusion.

Considerations:

- *MADE OF rules do not guarantee that the baseline will include the entire contents of any made-of list. If a complete made-of list is to be assured of being included, then either the template should be designed to use *BUILT; or else the *MADE OF rules must be sufficiently all-embracing to cover the made-of list. For example:

  EXE | *HIGHEST
  * | *MADE OF

  This could be used to include all the made-of lists for the included EXE items, but only if the baseline scope is large enough to include every configuration part which was specified or implied in each of the build processes.

- *BUILT and *MADE OF rules are incompatible with *ALL rules. Neither *BUILT nor *MADE OF may be used in any template which contains one or more *ALL rules.

Related Topics

Rule Operation