When you define the search path directories in a specific order, the paths are concatenated so that items that are not in the lower level build areas are obtained from the higher level build areas. For example, a build at the SYSTEM TEST stage looks for source items from the SYSTEM TEST and higher level RELEASE build areas, but any changes in source items in the lower level DEVELOPMENT and UNIT TEST build areas are ignored. A build always compiles the active item revisions for the stage where the build is executed.
For example, assume that you have the following build stages and items:
Build stages |
Items and revision numbers |
||
UNIT TEST |
foo.c-3 |
|
|
SYSTEM TEST |
foo.c-2 |
boo.c-2 |
|
RELEASE |
foo.c-1 |
boo.c-1 |
goo.c-1 |
If you build at the RELEASE stage, foo.c-1, boo.c-1 and goo.c-1 are compiled:
Build stages |
Items and revision numbers |
||
UNIT TEST |
foo.c-3 |
|
|
SYSTEM TEST |
foo.c-2 |
boo.c-2 |
|
RELEASE |
foo.c-1 |
boo.c-1 |
goo.c-1 |
If you build at the SYSTEM TEST stage, foo.c-2, boo.c-2 and goo.c-1 are compiled:
Build stages |
Items and revision numbers |
||
UNIT TEST |
foo.c-3 |
|
|
SYSTEM TEST |
foo.c-2 |
boo.c-2 |
|
RELEASE |
foo.c-1 |
boo.c-1 |
goo.c-1 |
If you build at the UNIT TEST stage, foo.c-3, boo.c-2 and goo.c-1 are compiled:
Build stages |
Items and revision numbers |
||
UNIT TEST |
foo.c-3 |
|
|
SYSTEM TEST |
foo.c-2 |
boo.c-2 |
|
RELEASE |
foo.c-1 |
boo.c-1 |
goo.c-1 |