Glossary — EPICS-sumo 4.5.1 documentation

# 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.

buildtags

  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.