HOME
Generic Build Support (GBS) - User Manual
Introduction
Description
GBS requires a strict and rigid directory structure to facilitate automatic generation and interchange ability between Systems and SubSystems.
Sometimes separate parts of a system may not be able to use GBS (dedicated environment like Visual Studio, old code, etc.), they can however benefit from parts of the
concept of Generic Build Support, like the export mechanism which will be described later.
One of the advantages of Generic Build Support is that developers need not worry on how to generate the system.
Fixed sets of scripts, which work on all parts of the system, take care of this.
Because of this, all scripts work in the same way for each component and for each file.
This reduces the chance of mistakes considerably.
Additionally, because everything is defined, accidental misuse is avoided.
GBS gives flexibility where it is really needed. Everything else is fixed.
GBS provides the functionality to generate the directory-structure or parts of the directory-structure, automatically making sure all directories are properly named.
Users should never create directories manually.
Some basic definitions
SubSystem
The basic generation unit of GBS is a SubSystem.
SubSystems generate autonomously. I.e.: There are never direct references from one SubSystem to another.
At the end of the SubSystem generation a SubSystem will have generated one or more deliverables.
These can be executables, header-files, object-libraries, etc.
In GBS you want to minimise the number of SubSystems. Most systems will require only one SubSystem and that is good!
System
SubSystems are grouped into a System
Component
To be able to handle large amount of files in a SubSystem, files are distributed in containers called Components.
Typical population of a Component will be somewhere between 10 to 40 source-files.
It is often a good idea to map architectural components on GBS Components.
A GBS Component however, may very well contain more than one architectural component.
An executable usually has the following basic Component-structure:
Components COMP1 and COMP2 contain basic functionality.
Component BASE contains common functions and common header-files. (Or at least one header-file containing types common to COMP1 and COMP2 like 'bool', TRUE and FALSE, NULL, etc.)
The TOP Component contains the main.c file and the make-file for the executable.
References are 'downwards' only. There are no references between COMP1 and COMP2.
No matter how big an executable may become, it will always contain a 'TOP' Component with references 'down-ward', containing the main.c and the make-file for the executable.
It will also always contain a 'BASE' Component.
This is the Component all other Components refer to. (e.g.: dbg-modules, general header-file, etc).
It does not refer to other Components.
referring-to in this context means: including header-files, directly calling functions, directly accessing global variables and including of object-files/libraries during linking.
Build / BuildStream
A generation-sequence leading to a specific variant of a deliverable is called a BuildStream.
The generic name of the variant is the Build.
In GBS the directory-structure is set up in such a way that multiple BuildStreams generations can run in parallel for a SubSystem.
HOME
Generic Build Support (GBS) - User Manual 
Components COMP1 and COMP2 contain basic functionality.