Glossary
Here we define some of the terms used in the following text.
- alias
For each module in the dependency list there may be an alias definition. When a RELEASE file is created for a module, the variable names that are put into the file are the same as each modulename of each dependency except where an alias exists. In this case, the value of the alias is taken as variable name.
- aliases
See alias.
- build
A build is a set of modules where all modules are compiled. Information on all build is kept in the build database (BUILDS.DB). Each build has a unique buildtag.
- build database
See BUILDS.DB.
- builds
See build.
- BUILDS.DB
The build database. For further details see The build database.
- buildtag
A buildtag is a name that identifies each build. Information for each build can be found in the build database (BUILDS.DB) by looking up the buildtag.
See buildtag.
- command
This is an argument to a program that doesn’t start with a dash “-”. In all programs here, you can give only one command while there may be several commandline options. Commands may be immediately followed by command arguments.
- commandline option
This means an argument to a program that has the form “-[letter]” or “–[word]”. Some commandline options may require that an argument immediately follows the option.
- commandline options
See commandline option.
- commands
See command.
- configuration file
A file where values for some of the command line options can be specified. Youn usually prepare a configuration file globally or for your EPICS application or both. More details on this topic can be found at “configuration files “.
- dependencies
This means the set of every dependency of a module.
- dependency
A version of a module may depend on specific versions of other modules. This means that the module cannot be built and without all these other modules. A dependency is the modulename and versionname of one of these other modules.
- dependency database
See DEPS.DB.
- DEPS.DB
The dependency database. For further details see The dependency database.
- module
A module is a software package, an EPICS support module or an EPICS base. Each module has a modulename and a versionname.
Usually modules that have the same modulename share the same source tree but differ in their source versions.
A working copy of the source code of the module is placed in a support directory. and is usually managed by a version control system. The module is compiled in this directory, the binary files are installed within the directory structure.
- modulename
Each module has a unique name, the modulename. Note that each version of the same module has the same modulename.
- modulenames
See modulename.
- modules
See module.
- modulespec
This is a string that specifies a module and its version. Module specifications are an important concept in sumo, see also Module Specifications.
- modulespecifications
See modulespec.
- modulespecs
See modulespec.
- moduleversion
See version.
- moduleversions
See version.
- regular expression
A regular expression is a way to specify a pattern in order to match strings. For further information on regular expressions see re - Regular expressions. For an introduction to regular expressions see Regular Expression HOWTO.
- scan database
See SCANDB.
- SCANDB
This scan database is also called SCANDB. It is a file in JSON format which contains information on what version of a module was used which what version of a dependency. This file is not essential in order to use sumo. It can be used when you start using sumo in order to see what versions of modules are probably compatible with each other. If you start creating builds, this version information will also be gathered from your successful builds and at some point you will no longer need the scan database.
- scanfile
This is the file created by “sumo-scan all”. This JSON file can be converted to a DEPS.DB file with by “sumo db convert”.
- source
Each version of a module has a source. The source defines how we can obtain a copy of the sources for the version. Sumo supports paths and some version control systems in the source definitions.
- sources
See source.
- state
This is a string describing the maturity of a build. A state may be one of the following strings:
- stable
This set of modules is known to work.
- testing
This set of modules was built successfully.
- unstable
This set of modules is not yet built successfully.
- disabled
This set of modules should no longer be used by applications or newer builds. It has a defect or cannot be recreated due to changes in the dependency database.
- incomplete
This is the state of a build while it is created with “sumo build new”. When all module directories were created, it’s state is set to “unstable”.
- broken
This can happen if a build was to be deleted but some of the files couldn’t be removed. A build with this state can no longer be used and should be deleted soon.
- states
See state.
- support directory
This is the directory where the compiled versions of modules are stored.
- tag
This is a string that may by part of the source of a module. A tag helps to identify the version of the module within the version control system. In sumo, a versionname is always the same as the tag if the tag exists.
- version
A module has several versions. A version is a state of the module source directory that can be recreated anywhere either by copying a source directory or be checking out a version from the version control system with parameters that identify the version.
- versionname
In sumo, each version of a module has a versionname that is unique for that module. The modulename together with the versionname identify a specific version of the module.
- versionnames
See versionname.
- versions
See version.
- versionspec
This is a string that specifies the version of a module. See Module Specifications for further details.