any – the engine to build software, distributable in POSIX universe.
Description
The build of each package is described by file, called anybuild, build file, build script or just build. Commands in a build are written in shell and grouped into aimed methods like source fetching, configure, compile or packing.
Single build file may produce installable binary archives in formats for different package managers, for several platforms and with conformance to various development policies.
Tutorial documentation
- any-guide(7) - generic introduction, the description of basic working concepts, the description of work with the system in examples. Start with that guide.
- any-howto(7) contains brief summary of typical build tasks.
- any-build(7) describes in examples how to create a new anybuild.
Local pages in man and html
One may view the man documentation on build commands and functions like that:
any man <subject>
The any-man(1) command has the same syntax, as the system man(1).
Local docs in HTML format are located at doc/html/index.html.
any, anch
anch is the command, performing its next command inside isolated file environment (host, container), locating in the working directory. anch do is the semantic equivalent for chroot <workdir> ; any do
All commands, starting with any, may be launched with anch:
any do default package-1.2.3 # chrooted variant anch do default package-1.2.3 any build default package-1.2.3 # chrooted variant anch build default package-1.2.3 ... etc.
Reference documentation
For the work with existing packages:
- any-do(1) describes the main lauch utility and possibilities of the build through command line.
- any-workdir(7) describes the project directory to work with: its installation, inner structure and the purpose of each directory inside.
- any-conf(7) describes all options inside configuration files.
For debug and writing of the new builds:
- any-map(7) describes all essential methods and interfaces, which perform the actual building.
- any-api(7) describes all interfaces, provided by the engine for the use inside build scripts.
For project development:
- any-dev(7) describes the conventions about writing new code for the engine.
- any-distro(7) describes the creation of new build projects.
Specialized areas:
- anymods(7) lists the additional modules with support of version control systems, binary package formats and other outer infrastructure.
- rdd(1) low-level description of frontend: how the data is read from config files and how the launch of build process is implemented.
Glossary
- Working directory
-
Autonomous directory with full build suite. Working directories are isolated from each other and,
in case of chrooted / containerised environment, from host system as well.
See any-workdir(7)
for more details.
- Configs, configuration files, configuration options
-
All settings for the build process are stored in the configuration files of rdd(1)
at the root of working directory. Together with ports/
directory and fixed version
of any
aforesaid configuration files make up exhaustive input data to initialise the build.
- Ports directory
-
Directory with the individual build scripts for packages.
It also contains materials, generic to the package set, such as etalon data for checkers.
See any-workdir(7)
for more details.
- Package
-
Single unit of software to build.
Name of package or list with a number of names is the second in any-do(1)
launch string.
Package may be also referenced as binary package, meaning installable archive with target files and metainformation, intended for use with package manager. One source package can produce one or several binary archives. Software name inside package database may differ from original source one. In the any series of manuals the term package means source package or build-time entity, unless specified otherwise. - Package list
-
Plain text file with a list of packages to build them all in a single launch.
Each package is on a separate line, comments and empty lines are ignored.
Lists must be located at their own directory, ports/list/
as given
by default any.conf
config.
- Build id, build data, data words
-
One or several words, identifying the data to use for a build.
It's the first argument in any-do(1)
launch string.
The examples from the above commands are amd64
or amd64,packslack.
The first id, usually single short word, silently loads the whole data array with build options. That happens due to data sections in configs: they are chained together with reserved option rdd_prf_id in a manner that including of top level section (for example, amd64) involves the rest sections and their more generic data (say, all or any).
Variable AUSE inside the shell code contains all loaded data sections. See rdd(1) for details of data loading and any-api(7) for AUSE variable description. - Build profile
-
Single word, identifying the build inside working directory.
In simple case it is equal to build id, but in others not.
For build id amd64,packslack
build profile remains amd64.
Build profile is contained in paths to installed binary files, logs and other resulting stuff.
In general case build profile is constructed explicitly inside rdd(1) config files. The user must explicitly define which data words change the build profile and which do not. - Build map
-
Shell method, launched for build by default.
It contains sequence of essential methods, each with its own definite unique task.
See any-map(7)
for more details.
There can be other maps also, for example, map_autopre,
which contains sequence
of inner auxiliary methods to prepare the building:
output starting information to stdout, create needed temporary files.
- Launched methods
-
It is possible to launch arbitrary methods instead of predefined map method.
They are submitted as the third argument to any-do(1)
launch string.
Methods can refer to whatever subject, not only package building.
The main limitation to launched methods is absence of input parameters,
but they can use shell variables, provided by any-api(7).
- Anybuild, build file, build script, build
-
The shell file with methods and variables, unique for the package.
The most often methods to customise are
src_config(3),
src_compile(3)
and src_install(3).
Anybuild also contains interface variables, needed for generic build procedures,
such as dependencies handling. See any-build(7)
for details.
- Interface method
-
The method with fixed name, input data and conventions of its effect.
Interfaces describe the structure of some subsystem, allowing its various implementations.
Different implementations of the structurally same functionality are provided by
modules and extensions, and the user can choose one of them on the fly
with cmd or by config file.
For example, pkg_config(3)
and pkg_pack(3)
can be implemented
with packdeb
or packslack
modules,
resulting the binary packages in debian or slackware format, respectively.
There are build interfaces, used inside anybuilds, and engine interfaces. Build interfaces are part of any-api(7) and any-map(7). Engine interfaces are described in any-dev(7). - Any API
-
Set of global shell variables and methods, allowed for use inside anybuilds.
Described by any-api(7).
- Engine module
-
Enhancement of the general engine, which is turned on with explicit setting
in config file or with data word, added to build id in command line.
Usually it is one or several shell libraries, installed to any/lib/.
But in general case module may contain new executable files and another materials as well.
Module may include its own config settings, declare new interfaces and variables
for anybuilds or engine, add new behaviour to standard interfaces.
Each module should ship its own description.
Modules are used to keep functionality, which is not generic to include it into core engine. For example, it is the work with some outer tool, which is not needed for all users and configurations. They are also used to reduce the minimal set of included functions. anymods(7) lists modules, available in parallel with core any engine.