Release RMC-06.02
(2024-04-29)
|
Contents
Description
Description
Definitions
Generic Build Support (GBS)
The process of building according to strict rules and a strict predefined directory structure.
This makes building an easy process to use and to handle.
Make-files can be generated because the directory structure is fixed for all SubSystems.
RMC
Randy Marques Consultancy. The originator of GBS.
GBS Version
In older GBS releases the GBS version syntax was R.VV and R.VV_YY-MM-DD.
Where R stands for Release, VV stands for Version and YY-MM-DD for ReleaseDate
With the move of GBS to OpenSource the need to identify the 'Releaser' arises: Given a Release/Version,
you would want to identify who built the Release/Version.
Additionaly the need for identifying a 'patch' arises.
Hence the new notation (Since RMC-06.02):
Proj-RR.VV and
Proj-RR.VV(-Patch)
Where
- Proj
- Stands for Project/Company that created this Release/Version.
- UpperCase letters and/or '_'. Keep short.
- RMC is reserved for the original creator of GBS: Randy Marques Consultancy
- RR
- Release
- 2 digits.
- VV
- Version.
- 2 digits.
-
- Patch
- Patch version.
- Numbers, Letters and/or '_'.
- Optional
GBS-WA or System
A single, whole GBS directory tree.
Contains SubSystems.
GBS-WAs or Systems are identified by their SystemName
You can have as many GBS-WAs as you want. Even multiple occurrences of the same.
A GBS-WA will always correspond with a total SCM work area.
SubSystem
An independent generation-unit within GBS
A directory-structure with files that, during generation, produce software that can be delivered (released) to other
SubSystems and/or end-customers.
A GBS SubSystem is not per se an architectural SubSystem.
SubSystems can contain one or more Components
The number of SubSystems should be limited
Most Systems will have only one SubSystem
Component
A files-container within a GBS SubSystem.
The lowest level directory-tree in GBS
Here the source and object files reside.
A GBS Component is not per se an architectural Component
GBS Component may very well contain more than one architectural Component and/or parts of architectural Components.
Files in Components cannot refer to files in Components of other SubSystems
Deliverable
The set of files produced by a SubSystem for use in another SubSystem or as final product.
Generally speaking the deliverables of a SubSystem will consist of one or more libraries with one or more header-files.
In a broader sense, any file that has to be made available to another SubSystem is a deliverable.
(final executables, test-scripts, etc)
You can also have internal deliverables. A SubSystem may 'deliver; to another Subsystem.
Build or BuildStream
A sequence of compilations for a specific build, with a specific compiler toolchain, using the same set of
compile-options, possibly followed by linking, resulting in a deliverable.
Auditing
Actions performed on the code that do not generate executable code.
Think of Source Code Analysers (SCAs) like PCLint, C++Test or QAC
Auditing runs on file level, just like compilers
Note:
Doxygen runs on System level. It is therefore not considered an Auditing tool but a System Tool
Archiving
The process of placing one or more object files into an object library
GBS Administrator
Person responsible for the infrastructure of a GBS-WA.
Typical GBS responsibilities:
- Create the GBS-WA
- Create and maintain SubSystems, Components, Builds, Scope-files, etc.
- First line support for users of the GBS-WA
- Keep the GBS-WA healthy
This function may very well correspond with that of the SCM Manager
GBS Integrator
Person responsible for the execution of Generic functions in a GBS-WA.
Typical GBS responsibilities:
- Consolidate Audit results
- Set GBS Version Limits
This function may very well correspond with that of the SCM Manager
Hard versioned directories
A method to store multiple versions of something (programs, files, etc.) so that all are available at the same time.
This in contrast to Soft versioned directories that are stored inside SCM repositories and need to be checkout
before they can be accessed.
All versions reside under the ROOT directory. The versions are called REL. And the actual location is called PATH.
3 Environment Variables are used to define the actual location:
- app_ROOT e.g.: /opt/bin/perl
- app_REL e.g: v5.10.1.817
- app_PATH is always the combination of app_ROOT and app_REL e.g.: /app_ROOT/app_PATH
In the applications and especially switch.gbs you always use app_PATH (and maybe occasionally app_REL)
This assures that when you want to switch to another version you only need to change the app_REL
This method is used heavily throughout GBS
Builder
In the context of this document a Builder is a program or script that takes care of one step of the build-process of a deliverable.
Typical builders are compilers, library-archivers and linkers.
Acronyms
| GBS | | Generic Build Support
| | RMC | | Randy Marques Consultancy
| | SCA | | Source Code Analyser
| | SCM | | Software Configuration Management
| | SCMS | | Software Configuration Management System
e.g. SubVersion, Git
| | WA | | Work Area
| | |
|
|
HELP HOME
Generic Build Support (GBS) - User Manual