GBS Release Notes
Contains up-to-the-minute release information about GBS.
GBS FAQ
Frequently Asked Questions
perl
command must be either in the PATH or
specified via an Environment-Variable (GBS_PERL_PATH)._gbssetup.bat
(Windows) (Mind the '_'!) or. _gbssetup.sh
(Linux) (Mind the dot, the space and the '_'!)
... Development -+- Projects -+- systemname1 | +- systemname2 | +- systemname2_3.2 | +- GBSLogsRemember that GBS does not like spaces in directory and filenames and that they are case sensitive!
cd
to that directory (if you are not already there)swr --add
and answer the questions.swr --new
(below)swr --new
.cdlog | cd to the log directory as specified by GBS_LOG_PATH (or $HOME) |
cdroot | cd to current Root |
cddoc | cd to the doc of the current Root |
cddev | cd to the dev of the current Root |
cdext | cd to the ext of the current Root |
cdres | cd to the res of the current Root |
cdsys | cd to the sys of the current Root |
cdsysbuild | cd to the sysbuild of the current Root |
cdsysaudit | cd to the sysaudit of the current Root |
cdsystools | cd to the systools of the current Root |
cdsilo | cd to the silo of the current Root |
cdtmp | cd to the tmp of the current Root |
cdsub | cd to the current SubSystem directory |
cdbuild | cd to the gen of the current SubSystem |
cdaudit | cd to the audit of the current SubSystem |
cdcomp | cd to the comp of the current SubSystem |
cdimport | cd to the import of the current SubSystem |
cdexport | cd to the export of the current SubSystem |
cdapp | cd to the app directory of the current Non GBS SubSystem |
cdsrc | cd to the src directory of the current Component |
cdinc | cd to the inc directory of the current Component |
cdloc | cd to the loc directory of the current Component |
cdbld | cd to the bld directory of the current Component |
cdtarget | cd to the bld/Target directory of the current Component / Target |
cdaud | cd to the aud directory of the current Component |
cdopt | cd to the opt directory of the current Component |
cddat | cd to the dat directory of the current Component |
cdsav | cd to the sav directory of the current Component |
perl
command must be either in the PATH or
specified via an Environment-Variable (GBS_PERL_PATH).export GBS_PERL_PATH=/opt/ActivePerl-5.16
cd
to that directory
tar zxf downloaded-file
cd ActivePerl-5.16.version
./install.sh
+- 2.01 +- 2.01_2006-11-23 any_root -+- GBS -+- 2.02 +- 2.02_2007-08-05 +- 2.02_2007-09-15 <--GBS_SCRIPTS_ROOT--> <---GBS_SCRIPTS_REL--->
cd
to this directoryInstall.bat
cd
to this directorychmod u+x Install.sh
./Install.sh
_gbssetup.bat
(Windows) (Mind the '_'!) or. _gbssetup.sh
(Linux) (Mind the dot, the space and the '_'!)
gbs
' is used to startup GBS
C:\WinGW\2013072200
.swr --add
swr .
' to effectuate the edited switch.gbs
sws --new
swc --new
FOO bld/$GBS_TARGET/hello$GBS_BLD_GLK
FOO
with a few TABs and then '== mingw
' or '== gnuc
'sws --new
GBS | Generic Build Support | |
RMC | Randy Marques Consultancy | |
SCA | Source Code Analyser | |
SCM | Software Configuration Management | |
SCMS | Software Configuration Management System e.g. ClearCase, Continuus, SubVersion, Git | |
WA | Work Area | |
- doc | for documentation at system-level |
GBS works independently from a Software Configuration Management System (SCMS).
To ensure however, that GBS-managed files and directories are properly added to the SCMS, GBS provides support for a number of SCMSs:
During System (Root) creation (swr --new), one of the above (or 'None') may be selected.
If 'None' is selected, you are responsible for the proper handling of all SCMS aspects.
Note that gbsmaint offers a function to check and possibly add GBS-managed
files and directories to the selected SCMS.
REPOSITORY:--SCMS_ROOT------+ +--ext-- \ / DISK:--------GBS_PARENT_PATH--+--SYSTEM--+---dev-- \ DISK:<-------GBS_ROOT_PATH--------------> +--res--
SCMS | Repository | Data | Data Type |
---|---|---|---|
ClearCase | Implicit (VOB) | None | Irrelevant |
CVS | URL | SCMS_ROOT | Informational |
SVN | URL | SCMS_ROOT | Informational |
Git | None | SCMS_ROOT | Informational |
Synergy | EnvVar CCM_ADDR | None | Irrelevant |
VSS | EnvVar SS_DIR | SCMS_ROOT | Mandatory |
command --h | will give you short help | ||
command --h option... | will give you short help on the specified option(s) | ||
command --help | will give you more extensive help | ||
command --help option... | will give you long help on the specified option(s) | ||
--verbose[+|-] | Extensive logging messages if '' or '+' Always '+' in BATCH jobs (gbssys* commands) | ||
--inc file | will take the contents of file file as if it were typed on the commandline. Empty lines and lines starting with '#' are ignored. Multiple occurrence and nesting is allowed. |
bgpids
,
detab
,
filerep
,
fixeol
,
gbs
,
gbsaudit
,
gbsbldcheck
,
gbsedit
,
gbsexit
,
gbsexport
,
gbsgen
,
gbshelp
,
gbsinit
,
gbslocate
,
gbsmaint
,
gbsman
,
gbsscm
,
gbssetup
,
gbsshow
,
gbssilo
,
gbsstart
,
gbsstart_here
,
gbsstats
,
gbsswc
,
gbsswr
,
gbssws
,
gbsswt
,
gbssysaudit
,
gbssysgen
,
gbssysmake
,
gbssystool
,
gbsuninstall
,
gbswhich
,
gbsxref
,
grep
,
proto
,
swc
,
swr
,
sws
,
swt
,
tail
,
touch
,
win2unix
,
wordrep
USERS
| string array optional | <empty> == current user Default= |
-a[+|-]
| do_all boolean scalar optional | Include all processes Default=0 |
-f[+|-]
| do_fg boolean scalar optional | Include parent (foreground) processes Default=0 |
-k=process_to_kill
| integer scalar optional | Kill specified process-tree Default= |
--rel=rel
| string scalar optional | Specific GBS release. You can also specify 'cur', 'current' or '?' Default=. |
--noroot[+|-]
| noroot boolean scalar optional | Do not implicitly swr to current root Default=0 |
(GBS_) LOG_PATH | (GBS_) MODE | (GBS_) FLAGS_* |
(GBS_) APP_* |
subsystems
| string array optional | Specific SubSystems Default= |
--m=max_missing
| integer scalar optional | Cancel SubSys check after this many missing files Default=20 |
--targets=targets
| string array optional | (wild-)Targets to Build-Check. '' or '*' == All, '.' == Current Default= |
file
| string scalar mandatory | [[[subsys:]component:]subdir:[<subpath>/]]file Default= |
editor_opt
| string scalar optional | Editor option. e.g. Line-nr to jump to Default= |
--nco[+|-]
| no_checkout boolean scalar optional | .usr files will always be forced to no_checkout Default=0 |
export_file_locations
| string array optional | <Component>... and/or GEN: or SUB: . == Current Component. <empty> == <all> Default= |
--i[+|-]
| ignore_errors boolean scalar optional | Continue generation after error(s) Default=0 |
--c[+|-]
| cleanup_all boolean scalar optional | Delete all, independent from target Default=0 |
--show[+|-]
| show_actions boolean scalar optional | Show all actions Default=0 |
(GBS_) APP_* |
comp_file_opts
| string array mandatory | src files to generate with 'generate' options Default= |
--i[+|-]
| ignore_errors boolean scalar optional | Continue generation regardless of error(s) Default=0 |
--export[+|-]
| run_gbsexport boolean scalar optional | Run 'gbsexport' on completion Default=0 |
--mm[+|-]
| run_makemake boolean scalar optional | Run 'makemake' on completion Default=0 |
--jobs=jobs
| integer scalar optional range 1..9 | Max nr parallel jobs Default=2 |
(GBS_) DEBUGGER | (GBS_) MODE | (GBS_) OPT |
(GBS_) MAP | (GBS_) FLAGS_* | (GBS_) APP_* |
env_name
| string scalar mandatory | Env Variable to contain the filespec Default= |
file
| string scalar mandatory | The file to search Default= |
prefix
| string scalar mandatory | prefix string preceding all path-list elements. e.g: -I Default= |
path-list
| string array mandatory | The directories to search preceded by <prefix> Default= |
menu_entry_1
| integer scalar optional range 1..9 | Primary menu entry for single immediate execution Default=0 |
menu_entry_2
| integer scalar optional greater 0 | Secondary menu entry for single immediate execution Default=0 |
menu_entry_3
| integer scalar optional greater 0 | 3rd menu entry for single immediate execution Default=0 |
menu_entry_4
| integer scalar optional greater 0 | 4th menu entry for single immediate execution Default=0 |
menu_entry_5
| integer scalar optional greater 0 | 5th menu entry for single immediate execution Default=0 |
gbsman
menu_entry_1
| integer scalar optional range 1..7 | Menu entry for immediate execution Default=0 |
action
| string scalar optional choice: ?,all,full,versions | Action. Default is interactive ask Default= |
versions
| string array optional | Versions List Default= |
--brief[+|-]
| brief boolean scalar optional | Brief (short) listing Default=0 |
--ci[+|-]
| create_index boolean scalar optional | Create the HTML Index Default=1 |
--cs[+|-]
| create_summaries boolean scalar optional | Create the HTML Summaries Default=1 |
--vi[+|-]
| view_index boolean scalar optional | View index in HTML browser Default=1 |
--noc[+|-]
| no_create boolean scalar optional | No HTML Creation (forces --ci and --cs to '-') Default=0 |
steps
| string array optional | Steps and/or Aliases. <empty> == all select steps, 'ALL' == force all steps, '?' == show steps Default= |
--i[+|-]
| ignore_errors boolean scalar optional | Continue generation after error(s) Default=0 |
--vs[+|-]
| view_sum boolean scalar optional | View summary at completion Default=1 |
--audits=audits
| string array optional | (wild-)Audits to run. '' or '*' == All, '.' == Current Default=* |
--targets=targets
| string array optional | (wild-)Targets to Audit. '' or '*' == All, '.' == Current Default=* |
--files=files
| string array optional | Files to audit Default=*:*.* |
--aud[+|-]
| audit boolean scalar optional | Run audit Default=1 |
--sum[+|-]
| summary boolean scalar optional | Create summary Default=1 |
--fg[+|-]
| foreground boolean scalar optional | Runs in the foreground if set Default=0 |
--at=delay
| time ([+=]hh:mm or [+=]mm) scalar optional | Starting time (10:20), delta (+10:10) or now Default=now |
--sm[+|-]
| mail boolean scalar optional | Send mail on completion Default=0 |
--n[+|-]
| notify boolean scalar optional | Notify user on completion (bg/nowait only) Default=1 |
--wait[+|-]
| wait boolean scalar optional | Wait for completion of bg jobs Default=0 |
--jobs=jobs
| integer scalar optional range 1..9 | Max nr parallel jobs within a submitted job Default=2 |
--c=comment
| string scalar optional | Comments - will be shown in Summary - Specify %20 for space Default= |
(GBS_) LOG_PATH | (GBS_) FLAGS_* | (GBS_) APP_* |
steps
| string array optional | Steps and/or Aliases. <empty> == all select steps, 'ALL' == force all steps, '?' == show steps Default= |
--i[+|-]
| ignore_errors boolean scalar optional | Continue generation after error(s) Default=0 |
--mm[+|-]
| run_makemake boolean scalar optional | Run 'gbsmakemake' on completion of Full GBS SubSystems Default=1 |
--export[+|-]
| run_export boolean scalar optional | Run 'gbsexport' on completion Default=1 |
--targets=targets
| string array optional | (wild-)Targets to Build. '' or '*' == All, '.' == Current Default=* |
--fg[+|-]
| foreground boolean scalar optional | Runs in the foreground if set Default=0 |
--files=files
| string array optional | Files to gen Default=*:*.* |
--at=delay
| time ([+=]hh:mm or [+=]mm) scalar optional | Starting time (10:20), delta (+10:10) or now Default=now |
--sm[+|-]
| mail boolean scalar optional | Send mail on completion Default=0 |
--n[+|-]
| notify boolean scalar optional | Notify user on completion (bg/nowait only) Default=1 |
--wait[+|-]
| wait boolean scalar optional | Wait for completion of bg jobs Default=0 |
--jobs=jobs
| integer scalar optional range 1..9 | Max nr parallel jobs within a submitted job Default=2 |
--c=comment
| string scalar optional | Comments - will be shown in Summary - Specify %20 for space Default= |
(GBS_) LOG_PATH | (GBS_) DEBUGGER | (GBS_) MODE |
(GBS_) OPT | (GBS_) MAP | (GBS_) FLAGS_* |
(GBS_) APP_* |
steps
| string array optional | Steps and/or Aliases. <empty> == all select steps, 'ALL' == force all steps, '?' == show steps Default= |
--i[+|-]
| ignore_errors boolean scalar optional | Continue generation after error(s) Default=0 |
--smm[+|-]
| start_makemake boolean scalar optional | Pre-generate the make-file Default=1 |
--mm[+|-]
| run_makemake boolean scalar optional | Run 'gbsmakemake' on completion of Full GBS SubSystems Default=1 |
--export[+|-]
| run_export boolean scalar optional | Run 'gbsexport' on completion Default=1 |
--targets=targets
| string array optional | (wild-)Targets to Build. '' or '*' == All, '.' == Current Default=* |
--files=files
| string array optional | Files to make Default=*:*.* |
--fg[+|-]
| foreground boolean scalar optional | Runs in the foreground if set Default=0 |
--at=delay
| time ([+=]hh:mm or [+=]mm) scalar optional | Starting time (10:20), delta (+10:10) or now Default=now |
--sm[+|-]
| mail boolean scalar optional | Send mail on completion Default=0 |
--n[+|-]
| notify boolean scalar optional | Notify user on completion (bg/nowait only) Default=1 |
--wait[+|-]
| wait boolean scalar optional | Wait for completion of bg jobs Default=0 |
--jobs=jobs
| integer scalar optional range 1..9 | Max nr parallel jobs within a submitted job Default=2 |
--c=comment
| string scalar optional | Comments - will be shown in Summary - Specify %20 for space Default= |
(GBS_) LOG_PATH | (GBS_) DEBUGGER | (GBS_) MODE |
(GBS_) OPT | (GBS_) MAP | (GBS_) FLAGS_* |
(GBS_) APP_* |
steps
| string array optional | Steps and/or Aliases. <empty> == all select steps, 'ALL' == force all steps, '?' == show steps Default= |
--i[+|-]
| ignore_errors boolean scalar optional | Continue generation after error(s) Default=0 |
--vs[+|-]
| view_sum boolean scalar optional | View summary at completion Default=1 |
--fg[+|-]
| foreground boolean scalar optional | Runs in the foreground if set Default=0 |
--at=delay
| time ([+=]hh:mm or [+=]mm) scalar optional | Starting time (10:20), delta (+10:10) or now Default=now |
--sm[+|-]
| mail boolean scalar optional | Send mail on completion Default=0 |
--n[+|-]
| notify boolean scalar optional | Notify user on completion (bg/nowait only) Default=1 |
--wait[+|-]
| wait boolean scalar optional | Wait for completion of bg jobs Default=0 |
--jobs=jobs
| integer scalar optional range 1..9 | Max nr parallel jobs within a submitted job Default=2 |
--c=comment
| string scalar optional | Comments - will be shown in Summary - Specify %20 for space Default= |
(GBS_) LOG_PATH | (GBS_) FLAGS_* | (GBS_) APP_* |
root
| string scalar mandatory | System / Root: '-' == none, '.' == current, '!' == CWD, '!<abs_file/dir_spec>', '!!' == CWD = GBS_ROOT_PATH Default=! |
subsystem
| string scalar optional | SubSystem: '-' == none, '.' or '' == current Default= |
component
| string scalar optional | Component: '-' == none, '.' or '' == current Default= |
--target=target
| string scalar optional | Target: '-' == none, '.' or '' == current Default=. |
--audit=audit
| string scalar optional | Audit: '-' == none, '.' or '' == current Default=. |
--tool=tool
| string scalar optional | Toolt: '-' == none, '.' or '' == current Default=. |
--exec=execute_command
| string scalar mandatory | (GBS-)Command to execute. 'none' = OK Default= |
--rel=rel
| string scalar optional | Specific GBS release. You can also specify 'cur' or 'current' Default=. |
gbs_command
| string scalar mandatory | GBS command. e.g.: gbsgen Default= |
gbs_command_args
| string array optional | GBS command args, including --options Default= |
--lines[+|-]
| count_lines boolean scalar optional | Count lines in src, inc and loc Default=0 |
--cs[+|-]
| create_stats boolean scalar optional | Create the HTML Statistics Default=1 |
--vi[+|-]
| view_index boolean scalar optional | View index in HTML browser Default=1 |
component
| string scalar optional | Component: '' == ASK, '-' == none, '.' == current Default= |
--target=target
| string scalar optional | Target: '-' == none, '.' == current Default= |
--new[+|-]
| create_new_component boolean scalar optional | Create a new Component Default=0 |
--nocd[+|-]
| no_cd boolean scalar optional | Do not 'cd' to the selected directories Default=0 |
root_path
| string scalar optional | System / Root: '' == ASK, '-' == none, '.' == current, '!' == CWD, '!<abs_file/dir_spec>', '!!' == CWD = GBS_ROOT_PATH Default= |
subsystem
| string scalar optional | SubSystem: '-' == none, '.' == current Default= |
component
| string scalar optional | Component: '-' == none, '.' == current Default= |
--target=target
| string scalar optional | Target: '-' == none, '.' == current Default=. |
--audit=audit
| string scalar optional | Audit: '-' == none, '.' == current Default=. |
--tool=tool
| string scalar optional | Tool: '-' == none, '.' == current Default=. |
--new[+|-]
| create_new_root boolean scalar optional | Create a new System / Root Default=0 |
--add[+|-]
| add_root boolean scalar optional | Add a Root to the Roots List Default=0 |
--remove[+|-]
| remove_root boolean scalar optional | Remove a Root from the Roots List Default=0 |
--show[+|-]
| show_roots boolean scalar optional | Show the Roots List Default=0 |
--exec=execute_command
| string scalar optional | (GBS-)Command(s) to execute. 'none' = OK Default= |
--nocd[+|-]
| no_cd boolean scalar optional | Do not 'cd' to the selected directories Default=0 |
subsystem
| string scalar optional | SubSystem. '' == ASK, '-' == none, '.' == current Default= |
component
| string scalar optional | Component. '-' == none, '.' == current Default= |
--target=target
| string scalar optional | Target. '-' == none, '.' == current Default= |
--new[+|-]
| create_new_subsys boolean scalar optional | Create a new SubSystem Default=0 |
--nocd[+|-]
| no_cd boolean scalar optional | Do not 'cd' to the selected directories Default=0 |
target
| string scalar optional | Target: '' == ASK, '-' == none, '.' == current Default= |
--new[+|-]
| create_new_target boolean scalar optional | Create a new Target Default=0 |
--remove[+|-]
| remove_target boolean scalar optional | Remove a Target from the Targets List Default=0 |
file_or_type_or_comp
| string scalar optional | filetype or Component or filename or SubDir/filename or */filename Default= |
search_type
| string scalar optional | filetype to search Default= |
(GBS_) FLAGS_* |
IF "%WIN32UTILS_IN_PATH%"=="" THEN PATH=%GBS_SCRIPTS_PATH%\win2util;%PATH%
SET WIN32UTILS_IN_PATH=1
grep --help
egrep --help
agrep --help
tail --help
touch --help
which --help
cp --help
find --help
gawk --help
make --help
rm --help
sed --help
tar --help
files
| string scalar optional | Files to be parsed Default=*.c *.cpp *.oc *.pl *.pm |
files
| string scalar optional | Files to process or directory in case of -r Default= |
-t[+|-]
| test boolean scalar optional | test only - do not make modifications Default=0 |
-r[+|-]
| recurse boolean scalar optional | recurse directory looking for -f= files Default=0 |
-f=wild_files
| string array optional | wild-card files to process Default= |
-m=modulo
| integer scalar optional | The TAB size the file was created with Default=8 |
-s[+|-]
| smart_tabs boolean scalar optional | retab leading whitespace (modulo 8) Default=0 |
command
| string scalar mandatory choice: ? info state co ci unco mkdir mktxt add move ignore remove import connect stop select | Basic SCM Command Default= |
files
| string array optional | File / Directory List Default= |
--r[+|-]
| recursive boolean scalar optional | Add whole directory tree Default=0 |
win2unix files...
files
| string array mandatory | Files to convert Default= |
fixeol files...
files
| string array mandatory | Files to be fixed Default= |
command_or_commandsfile
| string scalar mandatory | Replace Command or filespec of file containing Replace Commands Replace Command: <delim><find><delim><replace><delim>[w|b|e|a|r][i] - w = find word, b = find begin word, e = find end word - a = find any, r = find Perl regular expression - i = ignore case of search string - \s in replace string is converted to single space commandsfile: Empty lines and lines beginning with '#' are ignored Default= |
files
| string scalar optional | Files to process Default= |
-t[+|-]
| test boolean scalar optional | test only - do not make modifications Default=0 |
-r[+|-]
| recurse boolean scalar optional | recurse directory looking for -f= files Default=0 |
-f=wild-files
| string array optional | wild-card files to process Default= |
command_or_commandsfile
| string scalar mandatory | Rename/Delete Command or filespec of file containing Rename/Delete Commands Rename/Delete Command: <delim><find><delim><replace><delim>[g|r][i] - g = glob rename (default) - r = Perl regular expression rename - i = ignore case of search string Empty <replace> deletes the file commandsfile: Empty lines and lines beginning with '#' are ignored Default= |
files
| string scalar optional | Files to process Default= |
-t[+|-]
| test boolean scalar optional | test only - do not make modifications Default=0 |
-r[+|-]
| recurse boolean scalar optional | recurse directory looking for -f= files Default=0 |
-f=wild-files
| string array optional | wild-card files to process Default= |
The gbssys... commands are used to perform actions involving more than one SubSystem.
gbssysgen | is used to generate a whole or part of a whole System |
gbssysmake | is used to 'make' a whole or part of a whole System |
gbssysaudit | is used to audit a whole or part of a whole System |
gbssystool | is used run a tool on the whole or part of a whole System |
These commands will perform their functions over various SubSystems in the appropriate order and allows extra steps to be executed.
It is also possible to generate a number of SubSystems selectively.
The generations steps, their required order and allowed options are defined in the
steps.gbs file (in $GBS_SYS_PATH).
Execution will be performed in the batch and the output is logged in a log-file.
gbssys... | [ steps ] [ GBS-options ] [ APP-options ] [ GBS-env-variables ] [ other_gbs_options ] |
TARGET | =... |
DEBUGGER | =,YES,NO |
MODE | =,FINAL,ASSERT,DEBUG |
OPT | =,YES,SPEED,SIZE,NO |
MAP | =,NO,YES |
FLAGS_MAKE | =... |
FLAGS_src_type | =... |
jobname | : gbssysgen gbssysmake gbssysaudit gbssystool' |
target_or_tool | : |
uname | : computer name and id |
os_root_spec | : $GBS_ROOT_PATH |
os_logfile_spec | : $GBS_LOG_PATH/$jobname_$target_$audit_$datetime.log |
time_start | : YYYY-MM-DD hh:mm:ss |
time_end | : YYYY-MM-DD hh:mm:ss |
time_diff | : hhh:mm:ss |
timer_diff | : "$clock $cpu_system $cpu_user $cpu_all" in seconds |
state | : NORMAL FAILED KILLED |
rc | : Return Code (Numeric. 0 == OK) |
audit | : or '-' |
date_time | : YYMMDD-hhmmss as used in os_logfile_name |
command_args | : From the command-line |
comment | : From the command-line (--c=...) |
<<EOF>> | : |
The generic syntax to specify files in GBSGEN, GBSMAKE and GBSAUDIT is:
[options1]... [ [[Component:][file]... [options2] ]...
The string is parsed left-to-right, setting the 'current-Component' as specified with Component:
Both Component and file may contain wild-cards.
file may be a comma-list, binding it to a possibly prefixed Component
options1 if present, will be passed to all file-generations
options2 if present, will be passed to all file-generations preceding the options2
options1 if present, will be passed to 'make'
options2 cannot be present in gbsmake. Use the GBS_FLAGS_type to specify options with gbsmake.
gbsgen my_file.c -DTEST comp1.c comp2:test.c -DTEST2
This results in:
There are predefined FLAGS for Debug-Mode, Debugger, Optimizer and Map-files
- Do not specify -G but DEBUGGER=YES
- Do not specify -DDEBUG but MODE=DEBUG
Full list:
Flags will be placed behind the generation scripts own flags in the following order
Include Paths are passed to the generation scripts in the following order
Note that the contents of the incs_TYPE.gbs files must refer to directories outside the current (Sub)System.
Do not prefix directories (with -I or -L)
The glb extensions are used to build libraries from object files.
For each library to be built there must be a glb-file in the source-directory, specifying the files to be included in the library.
The name of the library will be equal to the prefix of the glb-file, suffixed with the proper extension.
(e.q.: total.glb → total.lib)
'glb' Stands for GBS librarian
Specifying a file to be of the glb type tells GBS that the output files will be eligible for the -L statement while linking.
Description of the glb files can be found here.
The .glk extensions are used to build executables from object files and libraries.
For each executable to be built there must be a glk-file in the source-directory, specifying the files/libraries of the link.
The name of the executable will be equal to the prefix of the glk-file, suffixed with the proper extension.
(e.q.: total.glk → total.exe)
'glk' Stands for GBS linker
Specifying a file to be of the glk type tells GBS that -L statement will cause searching for libraries as generated by glb.
Description of the glk files can be found here.
The .glt extensions are used to test executables.
For each executable to be tested there must be a glt-file in the source-directory, specifying the executable and its parameters.
The output of the test (the log) will go to the target-directory.
The name of the logfile will be equal to the prefix of the glt-file, suffixed with .log.
(e.q.: total.glt → total.log)
'glt' Stands for GBS link test
Specifying a file to be of the glt type tells GBS that there may be special glt_ keywords in the glt file.
glt_ keywords must be specified at the top of the file, prefixed with '^',
followed by the executable-spec on a single line,
followed by the parameters, each on a single line.
Note:
The gbsexport command is used to copy files from Components and/or Gen or SubSystem to the export-directories:
The gbsaudit command will run an audit for one or more files in a Component.
It will generate a concatenated Audit output file optionally followed by a Summary.
The Summary is also generated in a separate file.
Upon completion the output file(s) are presented to the caller in a separate window.
The syntax of the gbsaudit command can be found here.
An Audit will only run for SubSystems that
Predefined audits can be installed with the gbsmaint command.
Executes the audit on all files in one or more or all SubSystems in a System (provided the SubSystem is enabled for the audit)
The syntax of the gbssysaudit command can be found here.
qac
GBSEXT_QAC_PATH | The main directory for QAC |
GBSEXT_QAC_REL | The selected QAC release |
Same way as for C-compilation
Note: #include "../../../file.h" notations are not handled correctly as they are not ANSI-C compliant.
Same way as for C compilations
qacpp
GBSEXT_QACPP_PATH | The main directory for QAC++ |
GBSEXT_QACPP_REL | The selected QAC++ release |
Same way as for C++-compilation
Note: #include "../../../file.h" notations are not handled correctly as they are not ANSI-C++ compliant.
Same way as for C++ compilations
pclint
GBSEXT_PCLINT_PATH | The main directory for PCLint |
GBSEXT_PCLINT_REL | The selected PCLint release |
Same way as for C and C++-compilation
Note: #include "../../../file.h" notations are not handled correctly as they are not ANSI-C/ANSI-C++ compliant.
Same way as for C and C++ compilations
export GBS_DEBUGGER=value
SET GBS_DEBUGGER=value
export GBS_MAP=value
SET GBS_MAP=value
export GBS_MODE=value
SET GBS_MODE=value
export GBS_OPT=value
SET GBS_OPT=value
export GBS_FLAGS_type_without_dot=values
SET GBS_FLAGS_type_without_dot=values
perl
is not in the PATHexport GBS_PERL_PATH=your_perl_path
SET GBS_PERL_PATH=your_perl_path
~/GBSLogs
%MY_DOCUMENTS%\..\GBSLogs
ON
$EDITOR, nedit, (gedit)
Notepad
Mozilla/Netscape
Default HTML Browser (Internet Explorer)
nedit -read
Notepad
None
None
Current
xtitle $1
TITLE %1%
GBS Startup
User File Templates
GBSEXT_scm_PATH
GBS_MAKE
GBS_SUBMIT
GBS_SUBWIN
GBS_BATCH
GBS_BG_NOTIFIER
ClearCase
LSF (Unix)
anydot_file_type
. E.g.: any.c, any.glk
cdsysbuild
, cd templates
and then gbsedit any.type
anydot_file_type
. e.g.: any.c, any.glk
%SYSTEM_NAME% | → System | |
%SUBSYS% | → SubSys | |
%COMPONENT% | → Component | |
%FILE% | → File_nameFile_type | |
%FILE_NAME% | → File_name | |
%FILE_TYPE% | → File_type | |
%UC_FILE% | → uc File_nameFile_type | |
%UC_FILE_NAME% | → uc File_name | |
%UC_FILE_TYPE% | → uc File_type | |
%INCLUDE_GUARD% | → uc File_nameFile_type with '.' replaced by '_' |
ClearCase | → GBSEXT_CC_PATH | |
IBM Rational Synergy | → GBSEXT_CCM_PATH | |
CVS | → GBSEXT_CVS_PATH | |
Git | → GBSEXT_GIT_PATH | |
Subversion | → GBSEXT_SVN_PATH | |
VisualSourceSafe | → GBSEXT_VSS_PATH |
--fg
)Submit: | submit | jobname datetime nr_jobs [ target action ]... |
Begin: | start | jobname datetime pid target action logfile-spec |
End: | end | jobname datetime pid target action logfile-spec completion-state completion-code Where completion-state is one of NORMAL FAILED or KILLED |
More | tbs | Expect future extensions |
Eclipse
,
Crimson Editor
,
Gedit
,
MS Visual Studio
,
Build Plugins are selected with gbsswt --new
And are updated with gbsmaint 7 1
Supported Build Plugins:
Audit Plugins are selected and updated with gbsmaint 7 1
Supported Audit Plugins:
See also audit.gbsTool Plugins are selected and updated with gbsmaint 7 1
Supported Tool Plugins:
See also tool.gbsSTEP doxygen_api TOOL = doxygen_api BUILD = NO AUDIT = NO STEP doxygen TOOL = doxygen EXEC = SPECIFY BUILD = NO AUDIT = NO
Supported Other Plugins:
STEP copy_export COMMAND = >copy_export/bin/copy_export.pl superglo $GBS_TARGET $GBSEXT_GBSSHARE/$GBS_TARGET AUDIT = NO
Level | EnvVar Name | Possible Values | Usage | More Info | Set by | Changed by | Remarks |
---|---|---|---|---|---|---|---|
1 Pre | GBS_PERL_PATH | directory path | Define location of Perl | More | User | User | Optional |
1 Pre | GBS_BASE_PATH | directory path | Define location of .gbs | gbsinit | N/A | Internal | |
1 Pre | GBS_HOME | directory path | Define a HOME-path | User | User | Deprecated | |
1 Pre | GBS_XTITLE | text | Define Window Title | More | User | User | Deprecated |
2 GBS | GBS_RC | Number | Scripts return status | various | scripts | ||
2 GBS | GBS_SITE | Short name in uppercase | Name your Site | More | gbsinit | gbssetup | |
2 GBS | GBS_LOG_ROOT | directory path | Log Files Root Location | More | gbsinit | gbssetup | Contains GBS_LOG_PATHs per GBS_ROOT_PARENT |
2 GBS | GBS_LOG_PATH | directory path | Log Files Location | More | gbsinit | switch.gbs | Set to $GBS_LOG_ROOT/$GBS_ROOT_PARENT |
2 GBS | GBS_BEEPS | YES NO | Beep | More | gbsinit | gbssetup | |
2 GBS | GBS_EDITOR | command_path | Editor to be used | More | gbsinit | gbssetup | |
2 GBS | GBS_BROWSER | command_path | Browser to be used | More | gbsinit | gbssetup | |
2 GBS | GBS_VIEWER | command_path | File viewer to be used | More | gbsinit | gbssetup | |
2 GBS | GBS_ADMINISTRATOR | System-names List | Defines Administrator | More | gbsinit | gbssetup | Internal |
2 GBS | GBS_INTEGRATOR | System-names List | Defines Integrator | More | gbsinit | gbssetup | Internal |
2 GBS | GBS_TEMPLATES_PATH | directory path | User Templates path (OPT) | More | gbsinit | swr | gbsall switch.gbs |
2 GBS | GBS_MAKE | command_path | Alternative 'make' (OPT) | More | gbsinit | swr | gbsall switch.gbs |
2 GBS | GBS_SUBMIT | command_path | Alternative Submit (Background) (OPT) | More | gbsinit | swr | gbsall switch.gbs |
2 GBS | GBS_SUBWIN | command_path | Alternative Submit (Foreground) (OPT) | More | gbsinit | swr | gbsall switch.gbs |
2 GBS | GBS_BATCH | command_path | Alternative Batch command (OPT) | More | gbsinit | swr | gbsall switch.gbs |
2 GBS | GBS_BG_NOTIFIER | command_path | Notifier for Submit completion (OPT) | More | gbsinit | swr | gbsall switch.gbs |
2 GBS | GBS_BUILD | RVVYYMMDD | Current Release/Build | More | gbsinit | Predefined | |
2 GBS | GBS_EXEC_MODE | INTERACTIVE FOREGROUND BACKGROUND | Execution Mode | gbsinit | gbssys* | Internal | |
2 GBS | GBS_GUI | Tkx None | Available Perl GUI | gbsinit | Predefined | Internal | |
2 GBS | GBS_PERL_CMD | perl with or without path | Direct Perl execution command | gbsinit | Predefined | ||
2 GBS | GBS_WPERL_CMD | perl with or without path | Command to start Perl GUI | gbsinit | Predefined | ||
2 GBS | GBS_PID | number | PID of toplevel process | gbsinit | Predefined | Internal | |
2 GBS | GBS_PLATFORM | Linux Win32 | Current platform | More | gbsinit | Predefined | Scripts |
2 GBS | GBS_SCRIPTS_ROOT | directory path | Where GBS versions are installed | More | gbsinit | gbssetup | Internal |
2 GBS | GBS_SCRIPTS_REL | version version_build | The current GBS version directory | More | gbsinit | gbssetup | Internal |
2 GBS | GBS_SCRIPTS_PATH | Root/Rel | The current GBS scripts location | More | gbsinit | gbssetup | |
2 GBS | GBS_SHELL_FILETYPE | .bat .sh | The current shell filetype | gbsinit | gbssetup | ||
2 GBS | GBS_VERSION | version (e.g.: 4.00) | The current GBS version number | More | gbsinit | Predefined | |
2 GBS | GBS_VERBOSE | 0 1 | Verbose logging | More | gbsinit | All Commands (Internally) | Always 1 in BATCH jobs (gbssys*) |
3 Root | GBS_SYSTEM_NAME | name | Name of the System/Root | More | swr | ||
3 Root | GBS_ROOT_PATH | directory path | Current system root | More | swr | ||
3 Root | GBS_ROOT_PARENT | directory name | Parent dir of current Root | More | swr | ||
3 Root | GBS_ALL_AUDITS | names list | All platform Audits | swr | |||
3 Root | GBS_AUDITS | names list | All Audits for this Platform | swr | |||
3 Root | GBS_AUDIT | name | Current Audit | swr | gbsaudit | ||
3 Root | GBS_AUDIT_PLUGIN | name | Current Audit Plugin | swr | gbsaudit | ||
3 Root | GBS_ALL_TARGETS | names list | All platform Targets | swr | |||
3 Root | GBS_TARGETS | names list | All Targets for this Platform | swr | |||
3 Root | GBS_TARGET | name | Current Target | swr | swt | ||
3 Root | GBS_TARGET_PLUGIN | name | Current Target Plugin | swr | swt | ||
3 Root | GBS_ALL_TOOLS | names list | All platform Tools | swr | |||
3 Root | GBS_TOOLS | names list | All Tools for this Platform | swr | |||
3 Root | GBS_TOOL | name | Current Tool | swr | gbssystool | ||
3 Root | GBS_TOOL_PLUGIN | name | Current Tool Plugin | swr | gbssystool | ||
3 Root | GBS_ALL_SUBSYSTEMS | names list | All SubSystems | swr | sws --new | ||
3 Root | GBS_IS_ADMINISTRATOR | 0 1 | User is Administrator | More | swr | gbssetup | |
3 Root | GBS_IS_INTEGRATOR | 0 1 | User is Integrator | More | swr | gbssetup | |
3 Root | GBS_SKIPTYPES | regexp List | Filetypes to be skipped | swr | Internal | ||
3 Root | GBS_PLATFORMS | Platform list | Platforms this root generates for | Internal | |||
3 Root | GBS_SCMS | None Subversion Git CVS ... | Current SCMS | More | swr | Internal | |
3 Root | GBS_SCMS_DATA | path | Internal Path | More | swr | Internal | |
3 Root | GBS_SCMS_REPOSITORY | file/directory path/URL | SCMS Repository location | More | swr | Internal | |
3 Root | GBS_SCM_SKIPTYPES | Regexp List | Filetypes for Current SCMS | More | swr | Internal | |
3 Root | GBS_DEV_PATH | directory path | ROOT/dev | More | swr | ||
3 Root | GBS_EXT_PATH | directory path | ROOT/ext | More | swr | ||
3 Root | GBS_RES_PATH | directory path | ROOT/res | More | swr | ||
3 Root | GBS_SILO_PATH | directory path | ROOT/silo | More | swr | Internal | |
3 Root | GBS_SYS_PATH | directory path | ROOT/sys | More | swr | ||
3 Root | GBS_SYSAUDIT_PATH | directory path | ROOT/sysaudit | More | swr | ||
3 Root | GBS_SYSBUILD_PATH | directory path | ROOT/sysbuild | More | swr | ||
3 Root | GBS_SYSTOOLS_PATH | directory path | ROOT/systools | More | swr | ||
3 Root | GBS_TMP_PATH | directory path | ROOT/tmp | More | swr | Internal | |
4 Sub | GBS_SUBSYS | name | Current SubSys | More | sws | ||
4 Sub | GBS_SSTYPE | GBS make MSVS Other | Current SubSystem Type | More | sws | ||
4 Sub | GBS_SUBSYS_PATH | directory path | ROOT/dev/SUBSYS | More | sws | ||
4 Sub | GBS_AUDIT_PATH | directory path | ROOT/dev/SUBSYS/audit | More | sws | ||
4 Sub | GBS_BUILD_PATH | directory path | ROOT/dev/SUBSYS/build | More | sws | ||
4 Sub | GBS_TOOLS_PATH | directory path | ROOT/dev/SUBSYS/tools | More | sws | ||
4 Sub | GBS_EXPORT_PATH | directory path | ROOT/dev/SUBSYS/export (OPT) | More | sws | ||
4 Sub | GBS_IMPORT_PATH | directory path | ROOT/dev/SUBSYS/import (OPT) | More | sws | ||
4 Sub | GBS_COMP_PATH | directory path | ROOT/dev/SUBSYS/comp | More | sws | SSTYPE==GBS | |
4 Sub | GBS_APP_PATH | directory path | ROOT/dev/SUBSYS/app | More | sws | SSTYPE!=GBS | |
5 Cmp | GBS_COMPONENT | name | Current Component | More | swc | SSTYPE==GBS | |
4 Cmp | GBS_COMPONENT_PATH | directory path | ROOT/dev/SUBSYS/comp/COMPONENT | More | swc | SSTYPE==GBS | |
5 Ses | GBS_DEBUGGER | YES NO | Include Debugger (build) | More | User | User | Scripts |
5 Ses | GBS_MAP | YES NO | Produce a memory map (linking) | More | User | User | Scripts |
5 Ses | GBS_MODE | FINAL ASSERT DEBUG PROFILING | Override Build mode | More | User | User | Scripts |
5 Ses | GBS_OPT | YES SPEED SIZE DEBUG NO | Override Optimisation | More | User | User | Scripts |
5 Ses | GBS_FLAGS_type | flags | Predefine flags (-D...) | More | User | User | Scripts |
6 Exe | GBS_BLD_src_type | File type | Derived Object filetype | More | gbsgen gbsmake | Scripts | |
6 Exe | GBS_IGNORE_ERRORS | 0 1 | --i was specified | More | gbssysgen gbssysmake | Scripts | |
6 Exe | GBS_FLAGS_type | flags or flags_file ref | Flags (-D...) | More | gbssys* gbsgen gbsaudit | Scripts | |
6 Exe | GBS_SYSFLAGS_type | flags or flags_file ref | System Flags (-D...) | More | gbssys* gbsgen gbsaudit | Scripts | |
6 Exe | GBS_INCS_type | includes or includes_file ref | Include Flags (-I...) | More | gbssys* gbsgen gbsaudit | Scripts | |
6 Exe | GBS_SYSFLAGS_type | includes or includes_file ref | System Include Flags (-I...) | More | gbssys* gbsgen gbsaudit | Scripts | |
6 Exe | GBS_MAKE_FLAGS | -i or empty | -i if GBS_IGNORE_ERRORS == 1 | More | gbssysgen | Scripts SSTYPE==make | |
6 Exe | GBS_MSBUILD_CONFIG | Debug Release or empty | Depends on GBS_MODE | More | gbssysgen | Scripts SSTYPE==MSVS |
EnvVar Name | Required for |
---|---|
GBSEXT_CC_PATH | ClearCase |
GBSEXT_CCM_PATH | IBM Rational Synergy |
GBSEXT_CVS_PATH | CVS |
GBSEXT_GIT_PATH | Git |
GBSEXT_SVN_PATH | Subversion |
GBSEXT_VSS_PATH | Visual Source Safe |
Type | Plugin | EnvVar | Required | Platform | Remarks |
---|---|---|---|---|---|
Builder | MinGW C | GBSEXT_MINGW_GCC | REL and PATH | Win32 | |
Builder | MinGW C/C++ | GBSEXT_MINGW_CPP | REL and PATH | Win32 | |
Builder | Microsoft Visual Studio 2012 - Simple Console C/C++ | GBSEXT_MSVS2012_CONS | REL and PATH | Win32 | |
Builder | Green Hills - BlackFin C/C++ | GBSEXT_GHSBF | REL and PATH | Win32 | |
Builder | GNU C | GBSEXT_LGNU_GCC | REL and PATH | Linux | |
Builder | GNU C/C++ | GBSEXT_LGNU_CPP | REL and PATH | Linux | |
Audit | PC-Lint C/C++ | GBSEXT_PCLINT | REL and PATH | Win32 | |
Audit | QAC | GBSEXT_QAC | REL and PATH | Both | |
Audit | QAC++ | GBSEXT_QACPP | REL and PATH | Both | |
Tool | Doxygen | GBSEXT_DOXYGEN | REL and PATH | Both |
The glkbt files (.glb, .glk, .glt and others) are located in the src, loc and/or inc directories and are used to specify the behaviour of builders that traditionally do not have 'source'-files, like Linkers and Archivers.
#====================================== # Src-File: software.glb # Component: software # SubSys: product_s #====================================== root$GBS_BLD_C #====================================== # Other Components #====================================== otv_arm:arm1$GBS_BLD_C otv_arm:arm2$GBS_BLD_C ###EOF###
#====================================== # Src-File: total_cze.glk # Component: software # SubSys: product_s #====================================== root$GBS_BLD_C root_country_cze$GBS_BLD_C rom_cze_gnu$GBS_BLD_C = gnu rom_cze_arm$GBS_BLD_C = arm software.lib #====================================== # Other Components #====================================== obs:occ$GBS_BLD_C obs:saoc$GBS_BLD_GLK #====================================== # Externals #====================================== .include total_libs.glk +rmgr_upc$GBS_BLD_GLB +country_czech$GBS_BLD_C +caxxconfiguration_cze$GBS_BLD_C +dvbst_stub$GBS_BLD_GLB ###EOF###
#======================================== # File: hello.glt # Component: test # SubSystem: superglo # System: SuperGlo_OK #======================================== .targets=mingw,mingwd ^call hello$GBS_BLD_GLK -par1 PAR2 ##EOF##
If a file exists with the same name and with extension .usr instead of .gbs then that file will be
taken instead of the .gbs file.
Never, ever check-in a .usr file.
To define the plugin.
The plugin-directory associated with the defined plugin will be added to a possible include-path.
It is used to find the plugin directory with .include
To include text from another .gbs file
To enable/disable EOL (End-Of-Line) Comments
To exclude generation of SRC files depending on the current Target
Only for glkbt files
To prematurely exit from a (included) file
To prematurely exit from a (included) file
The audit.gbs files are located in the GBS_SYSAUDIT_PATH/audit directories and are
used to associate file-extensions with audit-tools (QAC, QAC++ etc) for a specific audit.
Also the particularities of the auditing tools are defined.
Additional for this file:
To define general stuff, valid for the whole definition set.
To define derived Target dependent Environment Variables
Note that all references to the 'outside-world' must be specified in the
switch.gbs.
On Windows it can be used to (re)define an EnvVar with spaces removed.
(Converted to ShortPathName)
To associate a file-extensions with an audit program (like SCA) and provide the necessary information in order to be able to execute that audit program (executable or script).
To provide information on how to run the summary program (executable or script)
To provide the interface of an audit-related program that can be executed from the gbsmaint command
#======================================================== # [qac] audit.gbs #======================================================== .plugin qac .include <audit.gbs> ##EOF##
#======================================================== # [qacpp] audit.gbs #======================================================== SETUP NICE_NAME = QAC++ VIA_FORMAT = -via %s INIT SET_W = QAC_EXEC => qacpp SET_X = QAC_EXEC => qac++ SET = QACPPHELPFILES => $GBSEXT_QACPP_PATH/help BIN_DIR = SRC .cpp OUT_TYPES = .gout .met .err INC_FORMAT = -I %s SYSINC_FORMAT = -SI %s FLAG_FORMAT = -D %s SYSFLAG_FORMAT = FILE -SD %s COMMAND = 0,1 ; \ $GBSEXT_QACPP_BIN_PATH/$QAC_EXEC $GBS_INCS $GBS_SYSINCS $GBS_AUDIT_FLAGS $GBS_SYSFLAGS $GBS_FLAGS \ $2 $GBS_QACPP_FLAGS $* -outputpath $4 -n 1599 COMMAND = exists $GBS_ROOT_PATH/sysaudit/$GBS_AUDIT/style_ALL.nrf; ; \ $GBSEXT_QACPP_BIN_PATH/pal qacpp $2 $GBS_PAL_FLAGS -outputpath $4 COMMAND = exists $GBS_ROOT_PATH/sysaudit/$GBS_AUDIT/user_checks$GBS_SHELL_FILETYPE ; ; \ $GBS_ROOT_PATH/sysaudit/$GBS_AUDIT/user_checks$GBS_SHELL_FILETYPE qacpp $2 \ $GBS_INCS $GBS_SYSINCS $GBS_AUDIT_FLAGS $GBS_SYSFLAGS $GBS_FLAGS $* COMMAND = 0,1-9,99; \ $GBSEXT_QACPP_BIN_PATH/errdsp qacpp $2 $GBS_ERRDSP_FLAGS -outputpath $4 -file $2$5 SUMMARY COMMAND = ECHO SCA MAINT COMMAND = >qac/bin/prqamaint.pl QACPP ##EOF##
The export.gbs files located in the GBS_COMPONENT directories are used to specify which files of the Component are to be exported to a relative directory in RES/$GBS_SUBSYS and/or EXPORT when using the gbsexport command.
The export.gbs files located in the GBS_GEN directories are used to specify which files of any RES or EXT are to be exported to a relative directory in RES/$SUBSYS and/or EXPORT when using the gbsexport command.
The export.gbs files located in the GBS_SUBSYS directories (Non-GBS) are used to specify which files of the SubSystem, any RES and/or EXT are to be exported to a relative directory in RES/$SUBSYS and/or EXPORT when using the gbsexport command.
Files can be exported to $GBS_RES_PATH/$GBS_SUBSYS and/or to $GBS_EXPORT_PATH depending on the existence of these directories or selective by means if the to_base prefix.
Besides copying files it is also possible to create (msi) install programs.
By default:
Exported directories are created with mode: u=rwx,go=rx,o=x
Exported files are created with mode: ugo:r
Additional for this file:
#=============================== # [otv_al_s:ocs] export.gbs #=============================== RESSUB:inc/$GBS_TARGET == mingw inc/http_init.h inc/lsm.h inc/oco.h inc/ocs.h inc/ocs_cfg.h RESSUB:lib/$GBS_TARGET == mingw bld/$GBS_TARGET/ocs$GBS_BLD_GLB EXPORT:bin == mingw bld/$GBS_TARGET/ocs$GBS_BLD_GLBK|ugo:x ## EOF ##
#======================================================== # [profielsw] export.gbs #======================================================== base base/bin app\Task24Profiel\bin\Release\Task24Profiel.exe base/bin/DUT data\bin\DUT\_NL%20Profiel%20Leesmij.txt data\bin\DUT\CV%20TemplateB.dotm data\bin\DUT\leegcv.ini data\bin\DUT\wizard.ini base/bin/ENG data\bin\ENG\_English%20Profile%20ReadMe.txt data\bin\ENG\CV%20TemplateB.dotm data\bin\ENG\leegcv.ini data\bin\ENG\wizard.ini base/Doc data\Doc\Help.html data\Doc\userguide.doc base/Doc/Images data\Doc\Images\Balkknop.jpg data\Doc\Images\CVWizardMain.jpg data\Doc\Images\image002.jpg data\Doc\Images\TASK24.ico install INSTALL:%GBSEXT_ADVANCED_INSTALLER_PATH%\AdvancedInstaller.com /build Task24Profiel.aip setup.msi ###EOF###
The flags_type.gbs files are used to specify builder-specific flags.
The type specifies the associated source-file type (without the DOT)
The flags_type.gbs files may be placed in the following locations:
Additional for this file:
#======================================================== # [superglo::test]FLAGS_C.GBS #======================================================== -DTESTFLAG=1 ###EOF###
The gbssub batch file is used only for Non-GBS SubSystems, is located in the GBS_SUBSYS_PATH
directory and is used for the building or auditing of these Subsystems.
It is used by gbssysgen,
gbssysmake,
gbssysaudit and for Cleanup functions in gbsmaint.
@ECHO OFF ::============================================================================= :: [%SUBSYS%] gbssub.bat :: Requires 1 parameter: action :: Called to cleanup, gen, make or audit a non-GBS SubSystem :: For 'make' SubSystems ::============================================================================= :: :: Currently in $GBS_ROOT_PATH/dev/$GBS_SUBSYS :: Applicable EnvVars: :: GBS_TARGET :: GBS_TARGET_PLUGIN :: GBS_TARGET_PLUGIN_PATH ('make' or 'Other') :: GBS_TARGET_PLUGIN_BIN_PATH ('make' or 'Other') :: GBS_AUDIT_PLUGIN (for Audit only) :: GBS_AUDIT_PLUGIN_PATH (for Audit only) ('make' or 'Other') :: GBS_AUDIT_PLUGIN_BIN_PATH (for Audit only) ('make' or 'Other') :: :: Availabe EnvVars: :: GBS_ROOT_PATH :: GBS_SUBSYS :: GBS_SUBSYS_PATH :: GBS_AUDIT_PATH :: GBS_BUILD_PATH :: GBS_APP_PATH :: :: GBS_MAKE:: GBS_IGNORE_ERRORS 0 | 1 :: GBS_MODE FINAL | ASSERT | DEBUG | PROFILING :: GBS_OPT YES | SPEED | SIZE | DEBUG | NO :: GBS_DEBUGGER NO | YES :: GBS_MAP NO | YES :: :: GBS_BLD_ :: GBS_SYSFLAGS_ :: GBS_FLAGS_ also contains flags resulting from MODE, OPT, DEBUGGER and MAP :: GBS_SYSINCS_ :: GBS_INCS_ :: :: GBS_MAKE_FLAGS '-i' if GBS_IGNORE_ERRORS == TRUE :: ::============================================================================= setlocal set rc=0 set action=%1 :: :: Adjust for proper actions :: Just one to a few lines per action. Keep it simple. Do not try to be clever. :: Do not forget to set rc to proper exit value (0=success, >0=fail) :: if [%action%] == [cleanup_bld] goto CASE_CLEANUP_BLD if [%action%] == [gen] goto CASE_GEN if [%action%] == [make] goto CASE_MAKE if [%action%] == [cleanup_aud] goto CASE_CLEANUP_AUD if [%action%] == [audit] goto CASE_AUDIT goto CASE_DEFAULT :: :: CLEANUP_BLD :: :CASE_CLEANUP_BLD echo GBSSUB_: ** SubSys=%GBS_SUBSYS% - Target=%GBS_TARGET% - Action=%action% :: <== add your command(s) to execute the bld_cleanup here and remove these lines. :: Do not forget to set rc to proper exit value (0=success, >0=fail) :: <== Probably something like: %GBS_MAKE% clean -f Makefile.mk -i set rc=%ERRORLEVEL% goto CASE_END :CASE_GEN :: :: GEN :: echo GBSSUB_: ** SubSys=%GBS_SUBSYS% - Target=%GBS_TARGET% - Action=%action% :: <== add your command(s) to execute the gen here and remove these lines. :: Do not execute the 'clean' in this command. :: Do not forget to set rc to proper exit value (0=success, >0=fail) :: <== Probably something like: %GBS_MAKE% -f Makefile.mk -B -k %GBS_MAKE_FLAGS% set rc=%ERRORLEVEL% goto CASE_END :CASE_MAKE :: :: MAKE :: echo GBSSUB_: ** SubSys=%GBS_SUBSYS% - Target=%GBS_TARGET% - Action=%action% :: <== add your command(s) to execute the make here and remove these lines. :: Do not forget to set rc to proper exit value (0=success, >0=fail) :: <== Probably something like: %GBS_MAKE% -f Makefile.mk %GBS_MAKE_FLAGS% set rc=%ERRORLEVEL% goto CASE_END :CASE_CLEANUP_AUD :: :: CLEANUP_AUD :: echo GBSSUB_: ** SubSys=%GBS_SUBSYS% - Target=%GBS_TARGET% - Audit=%GBS_AUDIT% - Action=%action% :: <== add your command(s) to execute the audit_cleanup here and remove these lines. :: Do not forget to set rc to proper exit value (0=success, >0=fail) :: <== Probably something like: %GBS_MAKE% clean -f Makefile_aud.mk -i set rc=%ERRORLEVEL% goto CASE_END :CASE_AUDIT :: :: AUDIT :: echo GBSSUB_: ** SubSys=%GBS_SUBSYS% - Target=%GBS_TARGET% - Audit=%GBS_AUDIT% - Action=%action% :: <== add your command(s) to execute the gbssubaudit.bat here and :: remove these lines. :: Do not forget to set rc to proper exit value (0=success, >0=fail) :: <== Probably something like: :: %GBS_MAKE% -f Makefile_aud.mk -B -k %GBS_MAKE_FLAGS% echo GBSSUB_: No audits for non-GBS SubSystems set rc=%ERRORLEVEL% goto CASE_END :CASE_DEFAULT :: :: DEFAULT :: echo GBSSUB_: ***FATAL ERROR*** echo - Invalid action '%action%'. Must be one of (cleaunp_bld gen make cleanup_aud audit) set rc=9 goto CASE_END :CASE_END endlocal & set rc=%rc% exit /B %rc% :::EOF:::
The incs_type.gbs files are used to extend the search paths for builders beyond the Components.
The type specifies the associated source-file type (without the DOT)
They will specify directories in
The incs_type.gbs files may be placed in the following locations:
Additional for this file:
#======================================================== # [superglo]INCS_C.GBS #======================================================== $GBSEXT_DMF_PATH/include $GBSEXT_MARAP_PATH/inc ###EOF###
The owners.gbs file is located in the GBS_SYS_PATH directory is used to maintains 'owners' of SubSystems
and Components.
'Owners' have no meaning within GBS. It is offered as a convenience to be able to trace the
responsible person for a SubSystem or Component.
It has a specific internal structure and editing of the file is done via gbsmaint 9: 'Owners-file' Maintenance
* UserId Email Phone Owner-Name + uida1179 Paul.Lieverse@siemens.com +31-40-1234567 Paul Lieverse + uida1393 Leon.Bouwmeester@SiemensVDO.com +31-40-1234567 Leon Bouwmeester + uida1473 Datta.Inamdar@siemensvdo.com +31-40-1234567 Datta Inamdar + uida1641 Marcel.vanderVelden@siemensvdo.com +31-40-1234567 Marcel van der Velden + uida1667 Reinier.Kleefman@siemensvdo.com +31-40-1234567 Reinier Kleefman + uida1685 Martin.Smits.ext@siemens.com +31-40-1234567 Martin Smits * * SubSystem Component UserId = booter drv_flash uida1641 = booter - uida1641 = booter booter uida1641 = booter i_infolog uida1641 = main - uida1667 = main c_trusted_device_database uida1667 = main test_trace_mgr uida1685 = main most_fb_bluetooth_gateway uida1667 = main drv_iis uida1641 = main i_tracer uida1641 = main i_infolog uida1641 = main test_booter uida1641 = main c_phonebook_manager uida1667 = main a_ec_nr uida1179 = main zzz_comp2 uida1685 = main appl_p2er5 uida1685 = main a_mediarecorder uida1179 = main test_src uida1179 = main a_audiorouter uida1179 = main test_logger uida1641 = main c_bluetooth_phone uida1667 = main hal uida1641 = main base uida1393 = main i_logger uida1641 = main a_speechrecognition_lib uida1179 = main i_xtp uida1641 = main most_fb_speechrecognition uida1179 = main most_fb_linkcontrol uida1179 = main i_rtp uida1641 = main drv_sport uida1641 = main c_bluetooth_transfer_manager uida1667 = main test_autotests uida1473 = main test_most_stack uida1641 = main bsp_bf532dev uida1641 = main i_lifesign uida1641 = main a_speechrecognition uida1179 = main a_ec_nr_lib uida1179 = main i_ffs uida1641 = main h_flash_mgr uida1473 = main a_mediaplayer uida1179 = main most_fb_lifecycle uida1641 = main dq_mgr uida1641 = main zzz_comp1 uida1685
The sca_*.gbs files are used to define the behaviour of SCA Audits.
There are two types of sca_*.gbs files:
The sca_*.gbs files can be placed in the following locations:
Additional for this file:
#======================================================== # [SYSAUDIT:pclint[mingw]] sca_mingw.gbs #======================================================== .include sca_ALL.gbs ###EOF###and...
#======================================================== # [SYSAUDIT:pclint[ALL]] sca_ALL.gbs #======================================================== +E ALL +E 537 # Repeated include file name -E 1042 # At least one class-like operand is required with operator+Q $GBSEXT_MINGW_CPP_PATH +F NONE +T TLN=20,400:6001 ###EOF###
The scope.gbs files are located in the GBS_COMPONENT_PATH directory and are used to specify which Components are in scope.
Additional for this file:
#======================================================== # [OMS::test_no_unix:main]SCOPE.GBS #======================================================== superglo test_all = gnu ###EOF###
The steps.gbs file is located in the GBS_SYS_PATH directory is used to define the
order in which SubSystems are built or audited, Commands are executed or Tools are run.
Non-SubSystem steps, called 'Commands' allow you to execute commands to e.g.:
Copy end-results to a specific directory outside then GBS tree.
Tools run on the whole GBS tree and are not dependent on Audit or Target. E.g.: Doxygen, etc.
Additional for this file:
To define the order in which SubSystems must be generated
# # STEPS.GBS # # # STEPS # STEP begin COMMAND = @begin AUDIT = NO STEP superglo STEP bart STEP non_gbs STEP visualstudio STEP copy_export COMMAND = >copy_export/bin/copy_export.pl superglo $GBS_TARGET $GBSEXT_GBSSHARE/$GBS_TARGET AUDIT = NO STEP prqa EXEC = SPECIFY STEP doxygen TOOL = >doxygen/bin/doxygen.pl full BUILD = NO AUDIT = NO STEP doxygen_api TOOL = >doxygen/bin/doxygen.pl api EXEC = SPECIFY BUILD = NO AUDIT = NO # # ALIASES # ALIAS SUBSET STEPS = superglo bart ALIAS PRQA STEPS = prqa ALIAS FULL STEPS = superglo bart prqa ALIAS ALL STEPS = begin - doxygen_api ALIAS LGCC TARGET = lgcc ALIAS MINGW TARGET = mingw ##EOF##
The switch.gbs batch file is located in the GBS_ROOT_PATH directory and
is used to define the environment in which the System has to function.
Here all external items must be defined. e.g.:
@ECHO OFF ::======================================== :: %FILE% [%SYSTEM_NAME%] ::======================================== if NOT [%1] == [entry] goto :exit :: :: set items :: if NOT [%GBS_SITE%] == [%SITE%] goto :NOT_%SITE% :: :: %SITE% :: :: :: Version Control :: ::set GBSEXT_CC_PATH=PATH ::set GBSEXT_CCM_PATH=PATH ::set GBSEXT_CVS_PATH=PATH ::set GBSEXT_GIT_PATH=PATH ::set GBSEXT_SVN_PATH=PATH ::set GBSEXT_VSS_PATH=PATH :: :: Targets :: ::set GBSEXT_MSVS2012_ROOT=C:\Program Files (x86)\Microsoft Visual Studio 11.0 ::set GBSEXT_MSVS2012_SDK_ROOT=C:\Program Files (x86)\Microsoft SDKs\Windows ::set GBSEXT_MSBUILD_ROOT=C:\Windows\Microsoft.NET\Framework ::set GBSEXT_MINGW_ROOT=C:\MinGW :: :: Audits :: ::set GBSEXT_QAC_ROOT=C:\MyPrograms\PRQA\QAC ::set GBSEXT_QACPP_ROOT=C:\MyPrograms\PRQA\QACPP ::set GBSEXT_PCLINT_ROOT=C:\MyPrograms\PC-Lint :: :: Tools :: ::set GBSEXT_DOXYGEN_ROOT=C:\MyPrograms\doxygen :: :: GBS Settings :: goto :end_site :NOT_%SITE% if NOT [%GBS_SITE%] == [OTHER] goto :NOT_OTHER :: :: OTHER :: goto :end_site :NOT_OTHER echo ******* echo ** Unknown site '%GBS_SITE%' echo ** Must be one of [ %SITE% OTHER ] echo ******* ::false goto :error_exit :end_site :: :: Version Control :: ::set GBSEXT_SVN_PATH="C:\Program Files\TortoiseSVN\bin" ::set GBSEXT_SVN_PATH=PATH :: :: Targets :: ::set GBSEXT_MSVS2012_CONS_REL=2012 ::set GBSEXT_MSVS2012_CONS_PATH=%GBSEXT_MSVS2012_ROOT% ::set GBSEXT_MSVS2012_SDK_REL=v7.1A ::set GBSEXT_MSVS2012_SDK_PATH=%GBSEXT_MSVS2012_SDK_ROOT%\%GBSEXT_MSVS2012_SDK_REL% ::set GBSEXT_MSBUILD_REL=v4.0.30319 ::set GBSEXT_MSBUILD_PATH=%GBSEXT_MSBUILD_ROOT%\%GBSEXT_MSBUILD_REL% ::set GBSEXT_MINGW_BASE_REL=2013072200 ::set GBSEXT_MINGW_GCC_PATH=%GBSEXT_MINGW_ROOT%\%GBSEXT_MINGW_BASE_REL% ::set GBSEXT_MINGW_GCC_REL=4.8.1 ::set GBSEXT_MINGW_BASE_REL=2013072200 ::set GBSEXT_MINGW_CPP_PATH=%GBSEXT_MINGW_ROOT%\%GBSEXT_MINGW_BASE_REL% ::set GBSEXT_MINGW_CPP_REL=4.8.1 :: :: Audits :: ::set GBSEXT_QAC_REL=8.1-R ::set GBSEXT_QAC_PATH=%GBSEXT_QAC_ROOT%-%GBSEXT_QAC_REL% ::set GBSEXT_QACPP_REL=3.0-R ::set GBSEXT_QACPP_PATH=%GBSEXT_QACPP_ROOT%-%GBSEXT_QACPP_REL% ::set GBSEXT_PCLINT_REL=8.00x ::set GBSEXT_PCLINT_PATH=%GBSEXT_PCLINT_ROOT%\%GBSEXT_PCLINT_REL% :: :: Tools :: ::set GBSEXT_DOXYGEN_REL=3.5 ::set GBSEXT_DOXYGEN_PATH=%GBSEXT_DOXYGEN_ROOT% :: :: Audit Tools :: ::set QAC_REL=%GBSEXT_QAC_REL% ::set QACROOT=%GBSEXT_QAC_PATH% ::set QACPP_REL=%GBSEXT_QACPP_REL% ::set QACPPROOT=%GBSEXT_QACPP_PATH% goto end_entry_exit :exit if NOT [%1] == [exit] goto :no_entry_exit :: :: unset items :: (GBSEXT_... are all unset by GBS) :: set QAC_REL= set QACROOT= set QACPP_REL= set QACPPROOT= goto :end_entry_exit :no_entry_exit echo ***** echo ** SYSTEM/switch.gbs: Usage = call switch.gbs.bat [ entry ^| exit ] echo ***** goto :error_exit :end_entry_exit :: true goto :EOF :error_exit :: :: Error-exit :: set GBS_RC=1 goto :EOF :::EOF:::
#======================================== # %FILE% [%SYSTEM_NAME%] #======================================== SWITCH_RC=0 if [[ $1 = "entry" ]] then # # set items # if [[ $GBS_SITE = "%SITE%" ]] then # # %SITE% # # # Version Control # #export GBSEXT_CC_PATH=PATH #export GBSEXT_CCM_PATH=PATH #export GBSEXT_CVS_PATH=PATH #export GBSEXT_GIT_PATH=PATH #export GBSEXT_SVN_PATH=PATH # # Targets # #export GBSEXT_LGNU_GCC_ROOT=/usr/lib/gcc/x86_64-linux-gnu #export GBSEXT_LGNU_CPP_ROOT=/usr/lib/gcc/x86_64-linux-gnu # # Audits # #export GBSEXT_QAC_ROOT=/apl/cadappl_linux_ia32/qac #export GBSEXT_QACPP_ROOT=/apl/cadappl_linux_ia32/qac++ # # Tools # # # GBS Settings # true elif [[ $GBS_SITE = "OTHER" ]] then # # OTHER # true else echo "SWITCH.GBS: *****" echo "SWITCH.GBS: ** Unknown Site $GBS_SITE" echo "SWITCH.GBS: ** Must be one of '%SITE% OTHER'" echo "SWITCH.GBS: *****" SWITCH_RC=1 fi # # Targets # if [[ $SWITCH_RC = 0 ]] then # # Targets # #export GBSEXT_LGNU_GCC_REL=4.4.5 #export GBSEXT_LGNU_GCC_PATH=$GBSEXT_LGNU_GCC_ROOT/$GBSEXT_LGNU_GCC_REL #export GBSEXT_LGNU_CPP_REL=4.4.5 #export GBSEXT_LGNU_CPP_PATH=$GBSEXT_LGNU_CPP_ROOT/$GBSEXT_LGNU_CPP_REL # # Audits # #set GBSEXT_QAC_REL=8.1-R #set GBSEXT_QAC_PATH=$GBSEXT_QAC_ROOT-$GBSEXT_QAC_REL #set GBSEXT_QACPP_REL=3.0-R #set GBSEXT_QACPP_PATH=$GBSEXT_QACPP_ROOT-$GBSEXT_QACPP_REL # # Tools # true fi elif [[ $1 = "exit" ]] then # # unset items # (GBSEXT_... are all unset by GBS) # true else echo "SWITCH.GBS: *****" echo "SWITCH.GBS: ** switch.gbs.sh: Usage = . switch.gbs.sh [ entry | exit ]" echo "SWITCH.GBS: *****" SWITCH_RC=1 fi [[ $SWITCH_RC = 1 ]] && export GBS_RC=1 unset SWITCH_RC ##EOF##
The sys.gbs file is located in the GBS_SYS_PATH directory is used to define general settings
for generation and auditing.
Before GBS 3.00 this file was named sysbuild.gbs.
Additional for this file:
Allows environment-variables to be set while calling a GBS command on the command-line.
These environment-variables can then be used by the generation/audit
scripts.
For each variable a selection of value_names and optionally a value_string can
be set
They will be made available with GBS_APP_value_name and optionally
GBS_APP_value_name_VALUE
# # SYS.GBS # # # ENVIRONMENT VARIABLES # VARIABLE PROFILING VALUE = NO => NO VALUE = YES => YES VARIABLE COMPILER DEFAULT = GHS VALUE = GHS => -ghs VALUE = DIAB => -dia # # SRC EXCLUDES # EXCLUDE \.mcp$ \.cvs$ ##EOF##
The system.gbs file is located in the GBS_ROOT_PATH directory is used to define primary settings for a ROOT.
It is a very delicate file and any manual modifications should be left to a GBS specialist.
# # SYSTEM.GBS # id=system system_name=SuperGlo root_version=2.04 build_start=202061212 build_end= scms-MSWin32=SubVersioN scms-linux=No_SCMS scms_data=trunk scms_repository-linux= scms_repository-MSWin32=svn://vhvfsnt10/SuperGlo targets-MSWin32=dos targets-MSWin32=dosd targets-MSWin32=mingw targets-MSWin32=mingwd targets-MSWin32=mvs targets-MSWin32=mvsd targets-linux=lgcc ###EOF###
The target.gbs files are located in the GBS_SYSBUILD_PATH/target directories and is
used to associate file-extensions with builders (compilers, linkers, etc) for a specific target.
Also the particularities of the builders are defined.
Additional for this file:
To define general stuff, valid for the whole definition set.
To set Target dependent defaults, overriding the GBS defaults
To define derived Target dependent Environment Variables
Note that all references to the 'outside-world' must be specified in the
switch.gbs.
On Windows it can be used to (re)define an EnvVar with spaces removed.
(Converted to ShortPathName)
To associate a file-extensions with a builder and provide the necessary information in order to be able to execute the builder.
#======================================================== # [mingw] target.gbs #======================================================== SETUP NICE_NAME = MinGW_cpp INIT SET_W = TEST => WIN32 SET_X = TEST => LUNIX BIN_DIR = bin SETPATH = PATH => GBSEXT_MINGW_CPP_BIN_PATH% PATH SRC .c TYPE = c ORDER = 1 INC_TYPES = .h OUT_TYPES = .o INCLUDE_BLD = 1 INC_FORMAT = -I%s INC_SEARCH_STYLE = UNIX FLAG_FORMAT = -D%s MODE = ASSERT => -DASSERT MODE = DEBUG => -DDEBUG MODE = PROFILING => -DPROFILING DEBUGGER = YES => -g OPT = NO => -O0 OPT = SIZE => -Os OPT = SPEED YES => -O3 COMMAND = GBSEXT_MINGW_CPP_BIN_PATH%\gcc -c -Wall -ansi %GBS_INCS% %GBS_FLAGS% %* %2 -o %3 SRC .cpp TYPE = c ORDER = 1 INC_TYPES = .hpp OUT_TYPES = .o INCLUDE_BLD = 0 INC_FORMAT = -I%s INC_SEARCH_STYLE = UNIX FLAG_FORMAT = -D%s MODE = ASSERT => -DASSERT MODE = DEBUG => -DDEBUG MODE = PROFILING => -DPROFILING DEBUGGER = YES => -g DEBUGGER = NO => OPT = NO => -O0 OPT = SIZE => -Os OPT = SPEED YES => -O3 COMMAND = call GBSEXT_MINGW_CPP_BIN_PATH%\g++ -c -Wall %GBS_INCS% %GBS_FLAGS% %* %2 -o %3 SRC .s TYPE = asm ^\.include\s+(")(.*?)" ^\s*#.* ORDER = 1 INC_TYPES = .inc OUT_TYPES = .o INC_FORMAT = -I%s FLAG_FORMAT = -D%s COMMAND = call GBSEXT_MINGW_CPP_BIN_PATH%\as --warn --fatal-warnings %GBS_INCS% %GBS_FLAGS% %* %2 -o %3 SRC .glb TYPE = glb ORDER = 2 INC_TYPES = .glb OUT_TYPES = .a GLKB = VARIABLE COMMAND = call GBSEXT_MINGW_CPP_BIN_PATH%\ar -rvs %* %3 %GBS_GLKB% SRC .glk TYPE = glk ORDER = 4 INC_TYPES = .glk OUT_TYPES = .exe GLKB = VARIABLE UNIXLIB INC_FORMAT = -L%s MAP = YES => -Wl,-Map -Wl,%1 # DEBUGGER = NO => "Wl,-s" COMMAND = @mingw_glk.bat SRC .glt TYPE = glt ORDER = 5 INC_TYPES = .glt OUT_TYPES = .log COMMAND = >ALL/gbstest.pl ##EOF##
#======================================================== # [mingwd] target.gbs #======================================================== .plugin mingw_gcc .include <target.gbs> DEFAULTS MODE = DEBUG DEBUGGER = YES OPT = DEBUG ##EOF##
The tool.gbs files are located in the GBS_SYSTOOLS_PATH/tool directories and are used to define the particularities of a Tool.
Additional for this file:
To define general stuff, valid for the whole definition set.
To set Tool dependent defaults, overriding the GBS defaults
To define derived Tool dependent Environment Variables
Note that all references to the 'outside-world' must be specified in the
switch.gbs.
On Windows it can be used to (re)define an EnvVar with spaces removed.
(Converted to ShortPathName)
To provide information on how to run the Tool program (executable or script)
#======================================================== # doxygen_api [doxygen] tool.gbs #======================================================== .plugin doxygen .include <tool.gbs> ###EOF###
#======================================================== # [doxygen] tool.gbs #======================================================== .plugin doxygen .include <tool.gbs> DEFAULTS ACTION = FULL ###EOF###
#======================================================== # %TOOL% [doxygen] tool.gbs #======================================================== SETUP NICE_NAME = DoxyGen INIT BIN_DIR = bin RUN ACTION = API => api ACTION = FULL => full COMMAND = >doxygen/bin/doxygen.pl %1 %2 %3 %4 ##EOF##
QAC calculates metrics in three groups.
Function metrics are generated for all functions with a full definition.
File metrics are generated for each file analyzed.
Project metrics are calculated once per complete project, and are generated from cross-module analysis.
QAC++ calculates metrics in three groups.
Function metrics are generated for all functions with a full definition.
Class metrics are generated for each defined class.
File metrics are generated for each file analyzed.
All metrics, except LIN and TPP, ignore code that is disabled on evaluation of pre-processor directives.
That is, both the code in the source file and the #include'd files inside conditional pre-processor directives are ignored for all metrics except LIN and TPP.
For example:
#define A 10 #if 0 #include <stdio.h> /* Ignored by all except LIN, TPP */ int i; /* Ignored by all except LIN, TPP */ #else long i; #endif
These metrics are all calculated for the source code of an individual function. Some metrics are used in the definition of others, but there is no obvious sequence. They are described here in alphabetical order, for ease of reference. The complete list is as follows:
AKI | Akiyama's Criterion |
AV1 | Average Size of Statement in Function (variant 1) |
AV2 | Average Size of Statement in Function (variant 2) |
AV3 | Average Size of Statement in Function (variant 3) |
BAK | Number of Backward Jumps |
CAL | Number of Functions Called from Function |
CYC | Cyclomatic Complexity |
ELF | Number of Dangling Else-Ifs |
FN1 | Number of Operator Occurrences in Function |
FN2 | Number of Operand Occurrences in Function |
GTO | Number of Goto statements |
KDN | Knot Density |
KNT | Knot Count |
LCT | Number of Local Variables Declared |
LIN | Number of Code Lines |
LOP | Number of Logical Operators |
M07 | Essential Cyclomatic Complexity |
M19 | Number of Exit Points |
M29 | Number of Functions Calling this Function |
MCC | Myer's Interval |
MIF | Deepest Level of Nesting |
PAR | Number of Function Parameters |
PBG | Residual Bugs (PTH-based est.) |
PDN | Path Density |
PTH | Estimated Static Program Paths |
RET | Number of Return Points in Function |
ST1 | Number of Statements in Function (variant 1) |
ST2 | Number of Statements in Function (variant 2) |
ST3 | Number of Statements in Function (variant 3) |
SUB | Number of Function Calls |
UNR | Number of Unreachable Statements |
UNV | Unused or Non-Reused Variables |
XLN | Number of Executable Lines |
These metrics are all calculated for the source code in a complete translation unit (TU). They are listed alphabetically here for convenience. They are not calculated in this sequence. because of their derivation from each other:
BME | Embedded Programmer Months |
BMO | Organic Programmer Months |
BMS | Semi-detached Programmer Months |
BUG | Residual Bugs (token-based estimate) |
CDN | Comment to Code Ratio |
DEV | Estimated Development (programmer-days) |
DIF | Program Difficulty |
ECT | Number of External Variables Declared |
EFF | Program Effort |
FCO | Estimated Function Coupling |
FNC | Number of Functions in File |
HAL | Halstead Prediction of TOT |
M20 | Number of Operand Occurrences |
M21 | Number of Operator Occurrences |
M22 | Number of Statements |
M28 | Number of Non-Header Comments |
M33 | Number of Internal Comments |
OPN | Number of Distinct Operands |
OPT | Number of Distinct Operators |
SCT | Number of Static Variables Declared |
SHN | Shannon Information Content |
TDE | Embedded Total Months |
TDO | Organic Total Months |
TDS | Semi-detached Total Months |
TLN | Total Preprocessed Source Lines |
TOT | Total Number of Tokens Used |
TPP | Total Unpreprocessed Code Lines |
VAR | Total Number of Variables |
VOL | Program Volume |
ZIP | Zipf Prediction of TOT |
CCA | Total Number of Characters |
CCB | Total Number of Code Characters |
CCC | Total Number of Comment Characters |
These metrics are calculated for the classes in your source code. To calculate some of these metrics you must also have run the relevant cross-module analysis program. See Cross-Module Analysis in Chapter 4: Analysing Source Code. Class-based metrics are described here in alphabetical order for ease of reference:
CBO | Coupling between objects |
DIT | Deepest level of inheritance |
LCM | Lack of cohesion of methods within a class |
MTH | Number of methods available in class |
NOC | Number of immediate children |
NOP | Number of immediate parents |
RFC | Response for class |
WMC | Weighted methods per class |
These metrics are calculated once per complete project. The complete list is as follows:
NRA | Number of Recursions Across Project |
NEA | Number of Entry Points Across Project |
NFA | Number of Functions Across Project |
CYA | Cyclomatic Complexity Across Project |
Function-Based Metric
This metric is the sum of the Cyclomatic complexity (CYC) and the number of function calls (SUB). Although this is not an independent metric, it is included on account of its use in documented case histories. See Akiyama[1] and Shooman[2] for more details. The metric is calculated as:
[1] Akiyama, F. (1971) An Example of Software System Debugging, Proc. IFIP Congress 1971, Lbujlana, Yugoslavia, American Federation of information Processing Societies, Montvale, New Jersey.
[2] Shooman, M.L. (1983) Software Engineering, McGraw-Hill, Singapore.
Function-Based Metrics
These metrics (AV1, AV2, and AV3) measure the average number of operands and operators per statement in the body of the function. They are calculated as follows:
AVx = (N1 + N2) / number of statements in the function
where:
N1 is Halstead's number of operator occurrences.
N2 is Halstead's number of operand occurrences.
The AVx metrics are computed using ST1, ST2 and ST3 to represent the number of statements in a function. Hence there are three variants: AV1, AV2 and AV3 relating to the respective statement count metrics.
This metric is used to detect components with long statements. Statements comprising a large number of textual elements (operators and operands) require more effort by the reader in order to understand them. This metric is a good indicator of the program's readability.
Metric values are computed as follows:
AV1 = (FN1 + FN2) / ST1
AV2 = (FN1 + FN2) / ST2
AV3 = (FN1 + FN2) / ST3
Function-Based Metric
Jumps are never recommended and backward jumps are particularly undesirable. If possible, the code should be redesigned to use structured control constructs such as while or for instead of goto.
main() { Backward: switch (n) { case 0: printf( stdout, "zero\n"); break; case 1: printf( stdout, "one\n"); goto Backward; /* 1 */ break; case 2: printf( stdout, "two\n"); break; default: printf( stdout, "many\n"); break; } }
The above code sample has a BAK value of 1.
Function-Based Metric
This metric counts the number of function calls in a function.
It differs from the metric SUB, in that only distinct functions are counted (multiple instances of calls to a particular function are counted as one call), and also that functions called via pointers are not counted.
Function-Based Metric
Cyclomatic complexity is calculated as the number of decisions plus 1.
High cyclomatic complexity indicates inadequate modularization or too much logic in one function. Software metric research has indicated that functions with a cyclomatic complexity greater than 10 tend to have problems related to their complexity.
McCabe[3] gives an essential discussion of this issue as well as introducing the metric.
Example 1:
int divide( int x, int y) { if (y != 0) /* 1 */ { return x / y; } else if (x == 0) /* 2 */ { return 1; } else { printf( "div by zero\n"); return 0; } }
The above code sample has a cyclomatic complexity of 3 as there are two decisions made by the function. Note that correctly-indented code does not always reflect the nesting structure of the code. In particular, the use of the construct 'else if' always increases the level of nesting, but it is conventionally written without additional indentation and so the nesting is not visually apparent.
Example 2:
void how_many(int n) { switch (n) { case 0: printf( "zero"); /* 1 */ break; case 1: printf( "one"); /* 2 */ break; case 2: printf( "two"); /* 3 */ break; default: printf( "many"); break; } }
The above code sample has a cyclomatic complexity of 4, as a switch statement is equivalent to a series of decisions.
Some metrication tools include use of the ternary operator ? : when calculating cyclomatic complexity. It could also be argued that use of the && and || operators should be included. Instead, CYC calculation is based on statements alone.
CYC is one of the three standard metrics used by QAC for demographic analysis.
[3] McCabe, T. J. (1976) A Complexity Measure, IEEE Transactions on Software Engineering, SE-2, pp. 308-320.
Function-Based Metric
This is the number of if-else-if constructs that do not end in an else clause. This metric is calculated by counting all if statements that do not have a corresponding else and for which QAC issues a warning 2004. ELF provides a quick reference allowing monitoring of these warnings. The code sample below has an ELF value of 1.
int divide(int x, int y) { if (y != 0) { return x/y; } else if (x == 0) { return 1; } }
Function-Based Metric
This metric is Halstead's operator count on a function basis (N1). FN1 is related to OPT and M21: all of these metrics count 'operators', the difference is summarized as:
FN1 | Counts ALL operators in the function body |
M21 | Counts ALL operators in the file |
OPT | Counts DISTINCT operators in the file |
See OPT for the definition of an operator.
Function-Based Metric
This metric is Halstead's operand count on a function basis (N2). FN2 is related to OPN and M20: all of these metrics count 'operands', the difference is summarized as:
FN2 | Counts ALL operands in the function body |
M20 | Counts ALL operands in the file |
OPN | Counts DISTINCT operands in the file |
See OPN for the definition of an operand.
Function-Based Metric
Some occurrences of goto simplify error handling. However, they should be avoided whenever possible. According to the Plum Hall Guidelines, goto should not be used.
Function-Based Metric
This is the number of knots per executable line of code. The metric is calculated as:
The value is computed as zero when XLN is zero.
Function-Based Metric
This is the number of knots in a function. A knot is a crossing of control structures, caused by an explicit jump out of a control structure either by break, continue, goto, or return. KNT is undefined for functions with unreachable code.
This metric measures knots, not by counting control structure crossings, but by counting the following keywords:
The function below has an KNT value of 1.
void fn( int n, int array[], int key ) { while ( array[ n ] != key ) { if ( array[ n ] == 999 ) { break; } else { ++n; } } }
Function-Based Metric
This is the number of local variables of storage class auto, register, or static declared in a function. These are variables that that have no linkage. The function below has an LCT value of 2.
int other_result; extern int result; int test() { int x; /* 1 */ int y; /* 2 */ return (x + y + other_result); }
Function-Based Metric
This is the total number of lines, including blank and comment lines, in a function definition between (but excluding) the opening and closing brace of the function body. It is computed on raw code. LIN is undefined for functions which have #include'd code or macros which include braces in their definition.
The function below has an LIN value of 5.
int fn() { int x; /* 1 */ int y; /* 2 */ /* 3 */ return (x + y); /* 4 */ /* Comment Here */ /* 5 */ }
Long functions are difficult to read, as they do not fit on one screen or one listing page. An upper limit of 200 is recommended.
Function-Based Metric
This is the total number of logical operators (&&, ||) in the conditions of do-while, for, if, switch, or while statements in a function. The example function below has a LOP value of 2.
void fn( int n, int array[], int key ) { while (( array[n] != key ) && ( n > 0 )) { if (( array[n] == 999) || ( array[n] == 1000 )) { break; } else { ++n; } } }
Function-Based Metric
The essential cyclomatic complexity is obtained in the same way as the cyclomatic complexity but is based on a 'reduced' control flow graph. The purpose of reducing a graph is to check that the component complies with the rules of structured programming.
A control graph that can be reduced to a graph whose cyclomatic complexity is 1 is said to be structured. Otherwise reduction will show elements of the control graph which do not comply with the rules of structured programming.
The principle of control graph reduction is to simplify the most deeply nested control subgraphs into a single reduced subgraph. A subgraph is a sequence of nodes on the control flow graph which has only one entry and exit point. Four cases are identified by McCabe[4] which result in an unstructured control graph. These are:
However, if a subgraph possesses multiple entry or exit points then it cannot be reduced. The use of multiple entry and exit points breaks the most fundamental rule of structured programming.
The example below has a M07 value of 4.
void g( int n, int pos, int force ) /* M07 = 4 Cannot reduce control graph to Cyclomatic Complexity of 1 */ { int nlines = 0; while ( --n >= 0 ) { pos = back_line( pos ); if ( pos == 0 ) { if ( ! force ) { break; } ++nlines; } } }
[4] McCabe, T. J. (1976) A Complexity Measure, IEEE Transactions on Software Engineering, SE-2, pp. 308-320.
Function-Based Metric
This metric is a measure of the number of exit points in a software component and is calculated by counting the number of return statements. A function that has no return statements will have an M19 value of zero even though it will exit when falling through the last statement. This is regardless of whether the function is declared to have a return value or not (i.e. returns void). Calls to non-returning functions such as exit() or abort() are ignored by this metric.
The example below has an M19 value of 3.
void f( int a ) { return; /* 1 */ if ( a ) return; /* 2 */ a++; return; /* 3 */ }
Function-Based Metric
This metric is defined as the number of functions calling the designated function. The number of calls to a function is an indicator of criticality. The more a function is called, the more critical it is and, therefore, the more reliable it should be.
Function-Based Metric
This is an extension to the cyclomatic complexity metric. It is expressed as a pair of numbers, conventionally separated by a colon. Myer's Interval is defined as CYC : CYC + L
Cyclomatic complexity (CYC) is a measure of the number of decisions in the control flow of a function. L is the value of the QAC LOP metric which is a measure of the number of logical operators (&&, ||) in the conditional expressions of a function. A high value of L indicates that there are many compound decisions, which makes the code more difficult to understand. A Myer's interval of 10 is considered very high.
The example below has a MCC value of 3:4 because the cyclomatic complexity is 3 and there is one connective (&&) used in the conditions.
int divide( int x, int y) { if (y != 0) /* Condition 1 */ { return x / y; } else if (x == 0 && y > 2) /* Condition 2 */ /* Conditional expr 1 */ { return 1; } else { printf( "div by zero\n"); return 0; } }
Note:
In the calculation of MCC, the ternary operator (?:) is ignored.
When exporting metric values or displaying in the Metrics Browser, rather than attempting to display a value pair, the value of L is chosen for MCC.
Function-Based Metric
This metric is a measure of the maximum control flow nesting in your source code.
You can reduce the value of this metric by turning your nesting into separate functions. This will improve the readability of the code by reducing both the nesting and the average cyclomatic complexity per function.
The code example below has an MIF value of 3.
int divide( int x, int y) { if (y != 0) /* 1 */ { return (x/y); } else if (x == 0) /* 2 */ { return 1; } else { printf( "Divide by zero\n"); while (x > 1) /* 3 */ printf( "x = %i", x); return 0; } }
MIF is incremented in switch, do, while, if and for statements. The nesting level of code is not always visually apparent from the indentation of the code. In particular, an else if construct increases the level of nesting in the control flow structure but is conventionally written without additional indentation.
MIF is one of the three standard metrics used by QAC for demographic analysis.
Function-Based Metric
This metric counts the number of declared parameters in the function argument list. Note that ellipsis parameters are ignored.
Function-Based Metric
Hopkins, in Hatton & Hopkins[5] investigated software with a known audit history and observed a correlation between Static Path Count (PTH) and the number of bugs that had been found. This relationship is expressed as PBG.
PBG = log10 ( PTH )
[5] Hatton, L., Hopkins, T.R., (1989) Experiences With Flint, a Software Metrication Tool for Fortran 77, Symposium on Software Tools, Napier Polytechnic, Edinburgh, Scotland.
Function-Based Metric
This is a measure of the number of paths relative to the number of executable lines of code.
PDN = PTH / XLN
PDN is computed as zero when XLN is zero.
Function-Based Metric
This is similar to Nejmeh's[6] NPATH statistic and gives an upper bound on the number of possible paths in the control flow of a function. It is the number of non-cyclic execution paths in a function.
The NPATH value for a sequence of statements at the same nesting level is the product of the NPATH values for each statement and for the nested structures. NPATH is the product of:
Note:
else and default are counted whether they are present or not.
In switch statements, multiple case options on the same branch of the switch statement body are counted once for each independent branch only. For example:
switch( n ) { case 0 : break; /* NPATH of this branch is 1 */ case 1 : case 2 : break; /* NPATH for case 1 & case 2 combined is 1 */ default: break; /* NPATH for this default is 1 */ }
Since NPATH cannot be reliably computed if there are goto statements in the function, they are ignored by QAC for the purposes of calculating NPATH.
The following code example has a static path count of 26.
int n; if ( n ) { } /* block 1, paths 1 */ else if ( n ) { if ( n ) { } /* block 2, paths 1 */ else { } /* block 3, paths 1 */ /* block 4, paths block2+block3 = 2 */ switch ( n ) { case 1 : break; case 2 : break; case 3 : break; case 4 : break; default: break; } /* block 5, paths = 5 */ } /* block 6, paths block4*block5 = 10 */ else { if ( n ) { } /* block 7, paths 1 */ else { } /* block 8, paths 1 */ } /* block 9, paths block7+block8 = 2 */ /* block 10, paths block1+block6+block9 = 13 */ if ( n ) { } /* block 11, paths 1 */ else { } /* block 12, paths 1 */ /* block 13, paths block11+block12 = 2 */ /* outer block, paths block10*block13 = 26 */
Each condition is treated as disjoint. In other words, no conclusions are drawn about a condition that is tested more than once.
The true path count through a function usually obeys the inequality:
cyclomatic complexity <= true path count <= static path count
Static path count is one of the three standard metrics used by QAC for demographic analysis.
[6] Nejmeh, B.A. (1988), NPATH: A Measure of Execution Path Complexity and its Applications, Comm ACM, 31, (2), p. 188-200.
Function-Based Metric
RET is the count of the reachable return statements in the function, plus one if there exists a reachable implicit return at the } that terminates the function.
The following example shows an implicit return:
void foo( int x, int y ) { printf( "x=%d, y=%d\n", x, y ); /* Here with implicit return. Hence RET = 1*/ }
Structured Programming requires that every function should have exactly one entry and one exit. This is indicated by a RET value of 1. RET is useful when the programmer wants to concentrate on the functions that do not follow the Structured Programming paradigm. For example, those with switch statements with returns in many or every branch.
Function-Based Metrics
These metrics count the number of statements in the function body. There are 3 variants on the metric:
ST1 is the base definition and counts all statements tabulated below.
ST2 is ST1 except block, empty statements and labels are not counted.
ST3 is ST2 except declarations are not counted.
The following chart shows the statements counted by the STST metrics:
Statement Kind | ST1 | ST2 | ST3 |
block | yes | ignore | ignore |
simple statement followed by ; | yes | yes | yes |
empty statement | yes | ignore | ignore |
declaration statement | yes | yes | ignore |
label | yes | ignore | ignore |
break | yes | yes | yes |
continue | yes | yes | yes |
do | yes | yes | yes |
for | yes | yes | yes |
goto | yes | yes | yes |
if | yes | yes | yes |
return | yes | yes | yes |
switch | yes | yes | yes |
while | yes | yes | yes |
The following example shows statements counted by ST1, which for this function yields a value of 10:
void stst( void ) { int i; /* 1 */ label_1: /* 2 */ label_2: /* 3 */ switch ( 1 ) /* 4 */ { /* 5 */ case 0: /* 6 */ case 1: /* 7 */ case 2: /* 8 */ default: /* 9 */ break; /* 10 */ } }
This metric indicates the maintainability of the function. Number of statements also correlates with most of the metrics defined by Halstead. The greater the number of statements contained in a function, the greater the number of operands and operators, and hence the greater the effort required to understand the function. Functions with high statement counts should be limited. Restructuring into smaller sub-functions is often appropriate.
Function-Based Metric
The number of function calls within a function. Functions with a large number of function calls are more difficult to understand because their functionality is spread across several components. Note that the calculation of SUB is based on the number of function calls and not the number of distinct functions that are called, see CAL.
A large SUB value may be an indication of poor design; for example, a calling tree that spreads too rapidly.
See Brandl (1990)[7]
for a discussion of design complexity and how it is highlighted by the shape of the calling tree.
The following code example has an SUB value of 4.
extern dothis(int); extern dothat(int); extern dotheother(int); void test() { int a, b; a = 1; b = 0; if (a == 1) { dothis(a); /* 1 */ } else { dothat(a); /* 2 */ } if (b == 1) { dothis(b); /* 3 */ } else { dotheother(b); /* 4 */ } }
[7] Brandl, D.L. (1990), Quality Measures in Design, ACM Sigsoft Software Engineering Notes, vol 15, 1.
Function-Based Metric
This metric is the count of all statements within the function body that are guaranteed never to be executed. UNR uses the same method for identifying statements as metric ST1. Hence UNR counts the following as statements if unreachable.
Example yielding UNR = 4
void stunr( unsigned i ) { if ( i >= 0 ) { if ( i >= 0 ) { while ( i >= 0 ) return; } else /* unreachable */ { while ( i >= 0 ) return; } } return; /* unreachable */ }
Function-Based Metric
An unused variable is one that has been defined but which is never referenced. A non-reused variable is a variable that has a value by assignment but which is never used subsequently.
Such variables are generally clutter and are often evidence of 'software ageing', which is the effect of a number of programmers making changes. The code below has an UNV value of 2.
int other_result; extern int result; int test() { int y; /* Unused */ int z; z = 1; /* Non-Reused */ return (result + other_result); }
Function-Based Metric
This is a count of lines in a function body that have code tokens. Comments, braces, and all tokens of declarations are not treated as code tokens. The function below has an XLN value of 9.
void fn( int n ) { int x; int y; if ( x ) /* 1 */ { x++; /* 2 */ for (;;) /* 3 */ /* Ignore comments */ /* Ignore braces */ { switch ( n ) /* 4 */ { case 1 : break; /* 5 */ case 2 : /* 6 */ case 3 : /* 7 */ break /* 8 */ ; /* 9 */ } } } }
This metric is used in the computation of the KDN and PDN metrics.
Function-Based Metrics
The COCOMO metrics are produced for each source code file. You can display an estimate of development costs for a whole project by choosing the COCOMO Cost Model option from the Reports menu. See Chapter 6: Reports for a discussion of the COCOMO cost model and an explanation of the three programming modes: Organic, Semi-detached, and Embedded.
These metrics estimate the number of programmer-months required to create the source code in the respective environments.
BME = 3.6 * ( TPP / 1000 ) 1.20
BMO = 2.4 * ( TPP / 1000 ) 1.05
BMS = 3.0 * ( TPP / 1000 ) 1.12
Function-Based Metric
BUG = 0.001 * EFF2/3
This is an estimate of the number of bugs in the file, based on the number of estimated tokens. Its value would normally be lower than the sum of the function-based PBG values. For a more detailed discussion of software bug estimates, see Hatton and Hopkins,[8].
[8] Hatton, L., Hopkins, T.R., (1989) Experiences With Flint, a Software Metrication Tool for Fortran 77, Symposium on Software Tools, Napier Polytechnic, Edinburgh, Scotland.
Function-Based Metric
This metric is defined to be the number of visible characters in comments, divided by the number of visible characters outside comments. Comment delimiters are ignored. Whitespace characters in strings are treated as visible characters.
A large value of CDN indicates that there may be too many comments, which can make a module difficult to read. A small value indicates that there may not be enough comments, which can make a module difficult to understand.
The code below has 28 visible characters in comments and 33 visible characters in the code. The resulting CDN value is 0.85.
int test() /* This is a test */ { int x; int y; /* This is another test */ return (x + y); }
The value of CDN is affected by how QAC counts the comments. QAC can count comments in three possible ways:
Function-Based Metric
This is an estimate of the number of programmer days required to develop the source file. Unlike COCOMO statistics, which are based solely on the number of lines of code, this estimate is derived from the file's difficulty factor. It is a more accurate measure of the development time, especially after the scaling factor has been adjusted for a particular software environment.
DEV = EFF / dev_scaling
where dev_scaling is a scaling factor defined in qac.cfg. The default is 6000.
Function-Based Metric
This is a measure of the difficulty of a translation unit. An average C program has a difficulty of around 12. Anything significantly above this has a rich vocabulary and is potentially difficult to understand.
DIF = VOL / ( (2 + VAR) * log2 (2 + VAR) )
Function-Based Metric
This is a measure of the number of data objects (not including functions) declared with external linkage. It is an indication of the amount of global data being passed between modules. It is always desirable to reduce dependence on global data to a minimum.
extern int result; int other_result; main() { result = 20 + 30; other_result = result * 2; }
The above code sample has an ECT value of 2.
Function-Based Metric
This metric is a measure of the programmer effort involved in the production of a translation unit. It is used to produce a development time estimate.
Function-Based Metric
This metric is a count of the number of function definitions in the file.
Function-Based Metric
See Brandl[9]. Since the actual value of Brandl's metric requires a full, well-structured calling tree, FCO can only be an estimate. A high figure indicates a large change of complexity between levels of the calling tree. The metric is computed from FNC and the SUB values of the component functions in the translation unit:
The code example below has an FCO value of 1 (2 - 2 + 1).
BOOL isActive(CHANNEL c); BOOL okToRead(TEXTCHANNEL c) { return !isActive(c); } BOOL okToPrint(PRINTCHANNEL c) { return !isActive(c); }
Function-Based Metric
This metric and also ZIP are predictions derived from the vocabulary analysis metrics OPN and OPT of what the value of TOT should be. If they differ from TOT by more than a factor of 2, it is an indication of an unusual vocabulary. This usually means that either the source code contains sections of rather repetitive code or it has an unusually rich vocabulary. The two metrics are computed as follows:
ZIP = ( OPN + OPT ) * ( 0.5772 + ln (OPN + OPT) )
HAL = OPT * log2 ( OPT ) + OPN * log2 ( OPN )
Function-Based Metric
This metric is the number of operands in a software component and is one of the Halstead vocabulary analysis metrics. Halstead considered that a component is a series of tokens that can be defined as either operators or operands.
Unlike OPN, this metric is the count of every instance of an operand in a file, regardless of whether or not it is distinct. OPN only counts the operands that are distinct. The code example below has a M20 value of 8.
void f( int a ) /* 1,2 -> f, a */ { if ( a > 1 ) /* 3,4 -> a, 1 */ { ++a; /* 5 -> a */ while ( a > 1 ) /* 6,7 -> a, 1 */ { --a; /* 8 -> a */ } } }
Function-Based Metric
This metric is the number of operators in a software component and is one of the Halstead vocabulary analysis metrics. Halstead considered that a component is a series of tokens that can be defined as either operators or
operands.
Unlike OPT, this metric is the count of every instance of an operator in a file, regardless of whether or not it is distinct. OPT only counts the operators that are distinct. The code example below has a M21 value of 22.
void f( int a ) /* 1,2,3,4 -> void, (, int, ) */ { /* 5 -> { */ if ( a > 1) /* 6,7,8,9 -> if, (, >, ) */ { /* 10 ->{ */ ++a; /* 11,12 -> ++, ; */ while (a > 1) /* 13,14,15,16 -> while, (, >, ) */ { /* 17 -> { */ --a; /* 18,19 -> --, ; */ } /* 20 -> } */ } /* 21 -> } */ } /* 22 -> } */
Function-Based Metric
This metric is the number of statements in a software component. This is a count of semicolons in a file except for the following instances:
The code example below has a M22 value of 5.
void f( int a ) { struct { int i; int j; } ij; /* 1 */ a = 1; /* 2 */ a = 1; a = 2; /* 3,4 */ if ( a > 1 ) { return; /* 5 */ } }
Function-Based Metric
This metric is a count of the occurrences of C or C++ style comments in a source file except for those that are within the header of a file. A file header is defined as tokens preceeding the first code token or preprocessor directive token.
M28 is based on the method used to compute CDN but differs from CDN in that CDN counts the visible characters within comments, whereas M28 counts the occurrences of comments. The code example below has a M28 value of 2.
/* Header comment 1 Count = 0 */ /* Header comment 2 Count = 0 */ /* Last header comment Count = 0 code follows */ #define CENT 100 /* Non header comment Count = 1 */ void f( int a ) { /* Block scope comment Count = 2 */ a = CENT; return; }
Function-Based Metric
This metric is a count of C style or C++ comments in a source file that are within functions or annotate a line of code at file scope. Comments within functions are all comments at block scope. Comments that annotate code are ones that start or end on the same line as code.
M33 is based on the method used to compute CDN but differs from CDN in that CDN counts the visible characters within comments, whereas M33 counts the occurrences of comments. The code example below has a M33 value of 5.
/* Header comment 1 Count = 0 */ /* Header comment 2 Count = 0 */ /* Last header comment Count = 0 code follows */ #define CENT 100 /* Annotating comment M33 = 1 */ int /* Annotating comment M33 = 2 */ i; /* Annotating comment M33 = 3 */ int j; /* Annotating comment M33 = 4 */ /* Non internal comment M33 = 0 */ void f( int a ) { /* Block scope comment M33 = 5 */ a = CENT; return; }
Function-Based Metric
This is the number of distinct operands used in the file. Distinct operands are defined as unique identifiers and each occurrence of a literal.
Most literals, except 0 and 1, are usually distinct within a program. Since macros are usually used for fixed success and failure values (such as TRUE and FALSE), the differences in counting strategies are fairly minimal. The code below has an OPN value of 11.
extern int result; /* 1 -> result */ static int other_result; /* 2 -> other_result */ main() /* 3 -> main */ { int x; /* 4 -> x */ int y; /* 5 -> y */ int z; /* 6 -> z */ x = 45; /* 7 -> 45 */ y = 45; /* 8 -> 45 */ z = 1; /* 9 -> 1 */ result = 1; /* 10 -> 1 */ other_result = 0; /* 11 -> 0 */ return (x + other_result); }
Function-Based Metric
This covers any source code tokens not supplied by the user, such as keywords, operators, and punctuation. OPT is used in the calculation of a number of other metrics.
The code below has an OPT value of 11.
extern int result; /* 1,2,3 -> extern, int, ; */ static int other_result; /* 4 -> static */ main() /* 5,6 -> ()*/ { /* 7 -> { */ int x; int y; int z; x = 45; /* 8 -> = */ y = 45; z = 1; result = 1; other_result = 0; return (x + other_result); /* 9,10 -> return, + */ } /* 11 -> } */
Function-Based Metric
This metric is computed as the number of variables and functions declared static at file scope. The code example below has an SCT value of 2.
static int other_result; /* 1 */ int result; static int test() /* 2 */ { int x; int y; int z; z = 1; return (x + other_result); }
Function-Based Metric
Also known as the "entropy" H, this metric is a widely recognized algorithm for estimating the program space required to encode the functions in a source file. SHN is measured in bits and is calculated as follows:
SHN = ZIP * log2 (√(OPN + OPT) + ln (OPN + OPT))
Function-Based Metrics
The COCOMO metrics are produced for each source code file. You can display an accurate estimate of development costs for a whole project by choosing the COCOMO Cost Model option from the Reports menu. Refer to Chapter 6: Reports for a discussion of the COCOMO cost model and an explanation of the three programming modes: Organic, Semi-detached, and Embedded.
These metrics are a measure of elapsed time in months required to develop the source code in the respective environments.
TDE = 2.5 * BME 0.32
TDO = 2.5 * BMO 0.38
TDS = 2.5 * BMS 0.35
Function-Based Metric
This metric is a count of the total amount of lines in the translation unit after pre-processing. The pre-processed file will reflect the processing of include files, pre-processor directives and the stripping of comment lines.
Function-Based Metric
This metric is the total number of tokens, not distinct tokens, in the source file. The code example below has an TOT value of 19.
int test() /* 1,2,3,4 */ { /* 5 */ int x; /* 6,7,8 int y; /* 9,10,11 */ /*Excluded Comment*/ return (x + y); /* 12,13,14,15,16,17,18 */ } /* 19 */
Function-Based Metric
This metric is a count of the total number of source lines in the file before pre-processing.
Function-Based Metric
The metric represents the total number of distinct identifiers. The code below has an VAR value of 5.
int other_result; /* 1 */ extern int result; /* 2 */ int test() /* 3 */ { int x; /* 4 */ int y; /* 5 */ return (x + y + other_result); }
Function-Based Metric
This is a measure of the number of bits required for a uniform binary encoding of the program text. It is used to calculate various Halstead vocabulary metrics.
The following is the calculation for the program volume:
VOL = TOT * log 2 ( OPN + OPT )
Function-Based Metric
ZIP = ( OPN + OPT ) * ( 0.5772 + ln (OPN + OPT) )
See HAL.
Function-Based Metric
This metric is the total number of characters in the file. Only visible characters are counted, except in string or character literals, in which case all characters are counted and tabs are treated as one character. When counting comment characters, the comment delimiter characters are counted.
Function-Based Metric
This metric is the total number of code characters in the file. Only visible characters are counted, except in string or character literals, in which case all characters are counted and tabs are treated as one character. Characters comprising comments are not counted, this includes the comment delimiter characters.
Function-Based Metric
This metric is the total number of visible comment characters in the file. The comment delimiter characters are not counted.
Project-Wide Metric
This metric is defined to be the number of recursive paths in the call graph of the project's functions. A recursive path can be for one or more functions. The minimum, and often desirable, value of this metric is zero. Values greater than zero indicate the number of distinct loops in the call graph.
Project-Wide Metric
This metric is the number of functions that are not called in the project. It is the number of nodes in the call graph which are not themselves called. For example, main() is not called; hence the minimum (target) value of 1.
Project-Wide Metric
This metric is the number of function definitions in the project. Note that this metric is the sum of QAC's FNC metric values for each source file included in the project.
Project-Wide Metric
This metric is the sum of cyclomatic complexity values for each function definition in the project.
Note that this metric is the sum of QAC CYC metric values for each source file included in the project.
Class-Based Metric
This is a count of the number of methods (member functions) or member objects of other classes accessed by a class. Only classes outside the inheritance hierarchy are considered because you would expect interaction with base and derived classes. Coupling to classes outside the inheritance tree should be viewed with suspicion as it makes the class less independent and less re-usable. This is one of Chidamber & Kemerer's[10] suite of object oriented metrics.
[10] Chidamber, S.R. and Kemerer, C.F. (1991). Towards a Metrics Suite for Object Oriented Design, Proceedings of OOPSLA, '91, Sigplan notices, vol.26, no. 11, ACM Press.
Class-Based Metric
This represents the number of derivations from the furthest base class down to this class. A high figure may indicate that the class depends on accumulated functionality, which makes understanding the class potentially difficult. This is one of the metrics defined by Chidamber & Kemerer.
Class-Based Metric
Methods within a class are partitioned into sets that access independent sets of member objects. The LCM metric is a count of sets of unrelated members for a type.
For example (default):
class cohesive { private: int i1; int i2; int i3; public: void m1(int a) { i1 = a + i2; } void m2(int a) { i2 = a; } void m3(int a) { if (a > i3) ++i3; } };
This above code sample has a LCM value of 2 because methods m1 and m2 access the set of member objects i1 and i2. Method m3 accesses only i3 and can be viewed as independent of m1 and m2. (m3 is not cohesive with the other two methods).
Similarly, where one method calls another, the set used for inclusion in LCM is the union of the sets from each method.
Variations of the calculation of LCM may explicitly exclude constructors, so the default behavior of CMA is that constructors are excluded when calculating this metric. To include constructors, enable the configuration option "-ProdOption LCM::include_constructor".
If constructors are included, and the constructor for such a type initializes all the members, then the value of LCM is guaranteed to be '1'.
This is one of the metrics defined by Chidamber & Kemerer.
Class-Based Metric
The number of methods declared within a class. This does not include methods declared in base classes. Classes with a large number of methods will be difficult to understand.
Class-Based Metric
This is the number of classes for which this class is an immediate base class. A high figure for this metric indicates greater dependence on the functionality of this class, and more potential knock-on effects from changes to it. This is one of the metrics defined by Chidamber & Kemerer.
Class-Based Metric
This metric indicates the number of inheritances for a class. Root base classes have a value of 0 while classes derived with a single inheritance have a value of 1. Classes that have multiple inheritance are prohibited by some programming standards.
Class-Based Metric
This indicates how functions can potentially be called directly from the class. The response set is calculated as the number of distinct class methods and functions called from the definitions of those methods. This is one of the metrics defined by Chidamber & Kemerer.
Class-Based Metric
This is the sum of cyclomatic complexities (See Cyclomatic complexity (CYC) in Function-Based Metrics section of this document) for all the methods in the class. In the same way that cyclomatic complexity gives an indication of the amount of testing required for an individual function, this metric gives an indication of the amount of testing required for a whole class. This is one of the metrics defined by Chidamber & Kemerer.
Function structure diagrams show the control flow structures within source code. Decisions (if, switch, and the condition part of a loop) are displayed as forks in the structure. The corresponding join, further to the right, indicates where the paths rejoin. Backward arcs, caused by loops, are shown as dotted lines.
The function structure diagrams show the following code structures:
Each component progresses from the left to the right as the control flow would progress through the source code.
static int code = 0; void funcStraight( void) { code = 1; }
There is only one path through this particular function, which is represented as lying along the x-axis.
static int code = 0; void funcIf( void) { if (code > 0) { code = 1; } }
This function has two paths. The first path is through the if statement and is shown by the raised line. The second path is where the if condition is false and is represented by the x-axis.
static int code = 0; void funcIfElse( void) { if (code > 0) { code = 3; } else { code = 4; } }
This function has two execution paths. The first path is the if sub-statement represented by the raised line. The second path is the else sub-statement represented by the x-axis.
Note that the body of this structure is longer than the body of the if statement. If the two arms of the if-else were not straight line code, the body of the if branch would appear at the left hand end of the raised line and the body of the else branch would appear to the right of the lower line.
static int code = 0; void funcSwitch( void) { switch (code) { case 1: if (code == 1) { /* block of code */ } break; case 2: break; case 3: if (code == 3) { /* block of code */ } break; default: break; } }
In the switch statement, the x-axis represents the default action, and each case statement is shown by a raised line. The two briefly raised lines represent the if statements within case 1 and case 3.
The diagram shows how the if statements are staggered. The if of case 1 is shown on the left and the if of case 3 is shown on the right.
static int code = 0; void funcWhile( void) { while (code > 0) { --code; } }
In the while loop, the x-axis represents the path straight through the function as though the while loop had not been executed. The solid raised line shows the path of the while body. The dotted line shows the loop to the beginning of the while statement.
static int code = 0; void doSomethingWith(int); void funcFor( void) { int i; for (i = 0; i > code; ++i) { doSomethingWith( i); } }
The for loop is similar to the while loop as for loops can be rewritten as while loops. For example, funcFor in the above example could be written as:
void funcFor( void) { int i = 0; while (i > code) { /* body */ ++i; } }
static int code = 0; void funcWhileIfElse( void) { while (code > 0) { if (code == 1) { code = 0; } else { code--; } } }
This is an if-else contained within a while loop. The first solid raised line represents the while loop while the inner raised solid line represents the if-else loop. Other function structure components can be similarly nested.
static int code = 0; void funcWhileIfBreak( void) { while (code > 0) { if (code == 3) { break; } code--; } if (code == 0) { code++; } }
The break jumps to the end of the while statement and causes a knot. A knot is where the control flow crosses the boundary of another statement block and indicates unstructured code. In this case, break jumps to the end of the while statement and the next part of the program, the if statement, is executed.
static int code = 0; void funcWhileIfReturn( void) { while (code > 0) { if (code == 3) { return; } code--; } if (code == 0) { code++; } }
The return statement causes the program to jump to the end of the function. This jump breaks the control flow and causes a knot in the code.
static int code = 0; void funcWhileIfContinue( void) { while (code > 0) { if (code == 3) { continue; } code--; } if (code == 0) { code++; } }
The continue statement causes the program to jump back to the beginning of the while loop.
static void funcUnReach( int i) { if (i) { i = 1; } goto Bad;if (i) { i = 2; }Bad: if (i) { i = 3; } return; }
The raised red section represents code that is unreachable.
The structure and approximate position of the unreachable code is shown.
It occurs after the first if condition and before the last if condition.
Its position above the main structure shows that the control flow misses the middle if condition.
All Manual Pages | ![]() |