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