any-api is the set of global variables and interface methods, provided by any engine for build scripts.

All variables of core engine can be observed in any/corelib/api.sh. That file alone contains inclusion of entire engine code. Core functions are included explicitly. Also the modules are included, which are picked up according to the data words from configuration, as described in section Modular code inclusion of any-do(1). The input data for the build engine are variables from config files, constructed by rdd(1).

Shell variables, composing anybuild API, are in all-capital letters. Methods of API, allowed for using in anybuilds, are placed in any/corelib/interfaces.sh. Such methods also don't contain '_' separators in their names (methods use_enable, ause_enable make a historical exception). Besides API, anybuilds contain implementation of interface methods from any/corelib/map.sh and their counterparts. The rest methods of core engine set inside any/corelib/ are considered as inner and should not be used in anybuilds.

Additional interface methods are contained in files from any/lib/, additional interface variables are in files from any/include/. That files belong to modules of any(1) engine, which set up their allowed interfaces on their own. Each module should contain description of its public interface, exposed to anybuilds. Examples can be available inside anymods(7) listing.

any-dev(7) programming convention exists, which is wider, then any-api. It is used for extensions to the engine. Anybuilds are forbidden to use any-dev(7) API.

All variables are interpreted as strings, unless mentioned otherwise. The general convention is that variables must not contain symbols out of printable subset of ASCII.

When a variable is constructed from other API variables, they are listed as involved for current variable. Likewise the options from rdd(1) config files are mentioned.

When options or variables influences on some behaviour, concerning the described variable, they are listed as related for current variable.

When a variable can be set up directly from outer environment (not with option from config file), it is stated as preserves the outer value.

When a variable is available only with some data word or with some method call, the case is stated as well.

ANYAPI

Version of any-api.
The value is integer unsigned number. Version can be used to check compatibility of build engine with a project or with some extension module.

ANYARCH

Specialized architecture of built binaries.
The original meaning of the variable is CPU architecture. Examples of value:

power9

ultrasparc3

armv8

However, the distro project may put another sense into meaning of this variable.

If not set up explicitly, it is assigned the value all.

Values of this variable are checked by KEYWORDS mechanism.

Involved variables: HOSTARCH

Involved options: any_arch

Related variables: KEYWORDS

ANYARCHCAP

Capacity of built binaries.
32-bit or 64-bit in most cases.

If not set up explicitly, it is assigned the value 64.

Values of this variable are checked by KEYWORDS mechanism.

Involved options: any_arch_capacity

Related variables: KEYWORDS

ANYARCHENDIAN

The byte order in memory layout.
Possible values:

for little endian: little.

for big endian: big.

Values of this variable are checked by KEYWORDS mechanism.

Involved options: any_arch_endian

Related variables: KEYWORDS

ANYARCHMODE

Generalized architecture of built binaries.
Examples of value:

power

sparc64

aarch64

Generalized architecture is the family of more specialized architectures. For example, with value of power for ANYARCHMODE there could be specialized architectures power7, power8 and power9 as the value for ANYARCH.

If not set up explicitly, it is assigned the value all.

Values of this variable are checked by KEYWORDS mechanism.

Involved options: any_arch_family

Related variables: KEYWORDS

ANYDEVSRCDIR

Directory or path to locally developed sources.
Given sources are actively changing in a project, and are not taken as is, like materials from ANYSRCDIR. It is possible to add support of version control systems by including modules. The example is fetchdevgit(7) for work with git.

Stuff from ANYDEVSRCDIR is applicated on top of sources from ANYSRCDIR:

in case of plain files, they are copied on top of static sources from ANYSRCDIR;

in case of patches, they are applied on sources from ANYSRCDIR.

So it is possible for ANYDEVSRCDIR to keep and develop both full source set or separate additions to the original source state from third-party developers.

Involved variables: BASEDIR

Involved options: any_dev_src_dir

ANYOS

The base operation system for built binaries.
Examples of value:

linux

openbsd

redox

Values of this variable are checked by KEYWORDS mechanism.

Involved options: any_os

Related variables: KEYWORDS

ANYSRCDIR

Directory or path for static original sources: tarballs or extracted directories.
Given sources are copied to working directory as local files or from remote server. It is possible to add support for various access protocols by including modules. Example: fetchstatic(7) with support of scp.

Involved variables: BASEDIR

Involved options: any_src_dir

APROFILE

Name of build profile.
Profile acts as a string id of the build. That id participates in essential engine paths, such as WORKDIR, TMPDIR or IMGDIR.
For example, WORKDIR is formed as build/work/APROFILE/.

Build profile is not calculated automatically, but assigned explicitly with any_prof_core, any_prof_prefix, any_prof_postfix options. It is possible to assign whatever profile name for any configuration. If a user decides some configuration element (data word) leads to ABI change or some other effect, requiring separate build, he changes one or several options any_prof_* in according section of rdd(1) config.

For example, data words cap32 and cap64 mean different capacity for binary executable files and incompatibility between them. In that case it is possible to assign option any_prof_postfix=_32 for data word cap32 in section [cap32] of config file:

[cap32]
any_prof_postfix=_32

If APROFILE had value arch in general mode, it would become arch_32 after the change.

Change of the profile name means all binary materials will be located in separate catalogs and will not interfere with built packages of old profile. That helps to form two independent builds, going in parallel without mutual conflicts.

Involved options: any_prof_prefix, any_prof_core, any_prof_postfix

ARCH_FLAGS

Compile-time architecture-dependent flags.
The options to compiler, which are mandatory for current platform to generate correct code. They are already contained in more generic options ENGINE_* by default, but direct access to them can be useful as well.

The variable preserves outer value.

Involved options: any_arch_flags

ARCH_LDFLAGS

Link-time architecture-dependent flags.
The options to compiler at link stage, which are mandatory for current platform to generate correct code. They are already contained in more generic options ENGINE_* be default, but direct access can be useful as well.

The variable preserves outer value.

Involved options: any_arch_ldflags

AUSE

Variable with configuration of current launch session.
Configuration state is described by a set of words, called data words. Given words correspond to sections inside rdd(1) configuration files, which had been read. The values of options from that sections had formed the input data for current shell environment and variables from API.

The variable consists of unique data words in form of space-separated list, in order of their inclusion through rdd(1), the most right has the highest priority.

The variable is used in series of interface methods ause. ause meethods allow to build packages differently, depending on global conditions, stored in distro project configuration.

The variable is used for dynamic detection of which shell modules should be included. The description of the mechanism is given in any-do(1) in section Modular code inclusion.

Involved options: rdd_prf_all

BASEDIR

Root of the working directory.
It contains config rdd.def or directory rdd.conf.d/. In case of work inside container the variable contains absolute root: single slash symbol /. The engine expands the string, so that it always ends with / symbol.

Involved options: any_base_dir

BP

Full name with version for binary package.
Defaults to P.
Variable allows to create binary package with a name distinct from the one used within build system. That can be useful when naming conventions of package manager differs from generic names inside any(1).
Name and version should be joined with plain dash - here, like binpackage-1.2.3. If conventions of meta-information inside binary archive dictate other format, string will be converted automatically while creating the archive.

In case of several entries inside BP, separated by spaces, several binary packages are ordered to be produced from the current one. Each entry of BP contains name and version for single binary archive, thus packages with arbitrary combination of names and versions are possible, unlike in BPN. If BP is declared in build file with non-default value, it cancels the effect of BPN and BPV.
The conventions about creation of several binary packages are described in BPN.

Related variables: P, BPN, BPV

BPI

Version of binary package interface.
Defaults to PV or to a version by template N.M, see autobpi below.
When package packA is built against package packB, and BPI of packB equals to 1.2.3, the metainformation of packA contains the record >=packB-1.2.3 in dependencies. Without BPI the same record will be taken from RDEPEND of packA, for example, >packB-1.2.

The variable may be used to soften or harden the dependencies, when the package will be used in building of other packages. For the own dependencies of the package RDEPEND is applied, that's different functions.

For example, package hello-world-1.2.3 may declare BPI=1.2, thereby promising to keep binary compatibility for all releases 1.2.*. So the package, compiled against hello-world-1.2.3, must successfully work with hello-world-1.2.0 and hello-world-1.2.4. That means the dependencies of application-3.0 would have more soft value >=hello-world-1.2 instead of >=hello-world-1.2.3.

From the other hand, if the package hello-world-1.2.5 declares BPI=1.2.5, it means the changed public interface inside hello-world-1.2.5. Now the package application-3.0, built with hello-world-1.2.5, will not work on the machine with package hello-world-1.2.3. In dependencies of application-3.0 the record >=hello-world-1.2.5 will appear, which will not allow to install application-3.0 on the machine, until it does not have the package hello-world-1.2.5 or higher.

The build system supports autobpi mode. If it is turned on, BPI by default will be initialised with first two components from package version. For example, for version 1.2.3.4 the value 1.2 will be written to BPI. If BPI is declared explicitly in the build, such assignment is not done.
To turn the mode on it is needed to set up option any_bool_autobpi=1.

If BPI does not equal to PV (with explicit declaration or with autobpi mode), BPI value is written to package database inside ROOT/pkgdb/. That value will be extracted by other packages, which would use the current one, while their meta-information is generated.

Involved options: any_bool_autobpi

BPN

The name without version for binary package.
Defaults to PN. The package manager deals with that name at installation of archive with a package.

If BPN contains several entries, separated by spaces, several binary packages are ordered to be produced from the current one. Names of packages are taken from BPN, and version of each one equals to BPV. Names and versions are joined with dash - symbol.
The creation of several binary archives like

packname1

...

packnameN

requires directories like

IMGDIR/packname1-version/

...

IMGDIR/packnameN-version/

each one containing files for corresponding package.

Files are copied from D to IMGDIR/packnameN-version by image_split_pack(3) method or manually.
When single binary package is produced, its content is searched in IMGDIR/packname-version and then in D. So for a single resulting binary archive its files may be just left in D without additional copy somewhere else.

Any of variables BP, BPN, BPV must be set up in anybuild body out of methods src_* и pkg_*. Otherwise binary packages will recieve wrong names after a call of program lspkg -f or methods pkgbin, pkgname.

The effect of the variable is cancelled when BP is declared in build file with non-default value.

Related variables: PN, BP, BPV

BPV

Part of version for binary package, according to upstream.
Defaults to PV. It does not include inner version, which is set up statically with INNER_VERSION and RELEASE or calculated with method fetch_inner_version(3).

The effect of the variable is cancelled when BP is declared in build file with non-default value.

Related variables: PV, BP

CCLD

Resulting string to call compiler at link stage.
When a wrapper around toolchain is used, it helps to disctinct launch string and original compiler name. Without a wrapper the variable equals to PLAIN_CCLD.

The variable preserves outer value.

Involved variables: PLAIN_CCLD

CC

Resulting string to call C compiler.
When a wrapper around toolchain is used, it helps to disctinct launch string and original compiler name. Without a wrapper the variable equals to PLAIN_CC.

The variable preserves outer value.

Involved variables: PLAIN_CC

CONFIGCACHE

File with cache for configuration program of current package.
The module is needed to work with cache. The example is subconfig(7). Cache is composed from data, statically saved into one of subdirectories of METADIR. For subconfig module the directory is SUBCONFIG_DIR.
Also a module provides methods, which can be called before the configuration, to store the created cache in package sources and to influence the configuration. Fot subconfig module these methods are subconfig_cache_*.

Configuration cache is usually used for cross-compilation to set up the results of configuration tests, which cannot be run for target platform on host system.

Related variables: METADIR

Involved variables: T

CONTEXTDIR

Parent directory to keep build context for packages.

Involved variables: BASEDIR, APROFILE

Involved options: any_write_root

CPP

Resulting string to call preprocessor.
When a wrapper around toolchain is used, it helps to disctinct launch string and original compiler name. Without a wrapper the variable equals to PLAIN_CPP.

The variable preserves outer value.

Involved variables: PLAIN_CPP

CXX

Resulting string to call C++ compiler.
When a wrapper around toolchain is used, it helps to disctinct launch string and original compiler name. Without a wrapper the variable equals to PLAIN_CXX.

The variable preserves outer value.

Involved variables: PLAIN_CXX

CXXLD

Resulting string to call compiler at link stage for C++ object code.
When a wrapper around toolchain is used, it helps to disctinct launch string and original compiler name. Without a wrapper the variable equals to PLAIN_CXXLD.

The variable preserves outer value.

Involved variables: PLAIN_CXXLD

DESCRIPTION

Plain text description of the package.

DEPEND

Build time dependencies of current package.

Dependencies from DEPEND are handled by methods of any at build stage. Given type of dependencies differs in common case from run-time dependencies, which get into a binary package and are handled by package manager. RDEPEND serves for assignment of run-time dependencies.

Dependencies are the list of entries, separated by spaces or new lines. Single entry is the package name with range of allowed versions and can be one of the forms:

>=used-program-1.2.3

Package used-program must be of version 1.2.3 or higher.

>used-program-1.2.3

Package used-program must be of version strictly higher then 1.2.3.

=used-program-1.2.3

Package used-program must be strictly of version 1.2.3.

used-program-1.2.3

Package used-program must be of version 1.2.3 or higher (same as >=).

<used-program-1.2.3

Package used-program must be of version strictly lower then 1.2.3.

<=used-program-1.2.3

Package used-program must be of version 1.2.3 or lower.

Rules of dependencies handling:

The search for a package with given name goes in dir IMGDIR.

For candidates, found in IMGDIR, the version is extracted and compared with range from the entry of DEPEND. The comparison is done with algorithm of sort -V.

If there was no package with needed name in IMGDIR, or all versions of the needed package have not fitted the range, the dependency handling method prints keyword --nonresolved and returns with error.

If fitting package has been found, dependency handling method prints it out.

If there are several fitting packages, the variant with the largest version will be used.

The versions from PV of packages are compared. Inner versions do not participate in comparison.

Related variables: RDEPEND, HDEPEND

DISTBASEDIR

Root directory of ports, where current distro project is kept.

Involved options: any_rdd_root, rdd_atom_path

DISTDIR

Directory with anybuild file of current package.
Besides anybuild itself, this dir contains all files for creation of binary package, such as postinstall scripts.
The dir DISTDIR/patch/ is one of the variants to keep patches.

Involved options: any_rdd_root, rdd_atom_path

Involved variables: P

DUMP

File in shell with entire context for the current package.
The dump file is standalone shell script, which makes available all methods and variables of the engine and current package. Given file is used primarily during interactive debug outside of automated build environment.

Involved options: any_dump, rdd_atom_dumpdir

D

Directory for installation of the current package.
It serves as DESTDIR for make install inside src_install(3) method. It is used by many map methods also.

D contains empty directory, dedicated for the package. It is located inside IMGDIR. Each package after the build remains accessible via separate directory inside IMGDIR. The scheme allows:

-

to form the build context dynamically. When there is separate access to the files of each package, it is possible to quickly create a directory with files only from selected packages. That allows to create personal build context for each package, where only its dependencies are included. In such a way the control goes over sufficiency of assigned dependencies and over consistensy between them and package configuration. If some dependency is not mentioned, it will not be available during the build.

-

to check up the available build dependencies by the presence of the directory with a package.

See description of ROOT for more details about dynamic build context and control over dependencies.

Involved variables: IMGDIR, P

ENGINE_CFLAGS, ENGINE_CXXFLAGS

Compile-time default flags.
These options to compiler are needed for correct build in any environment. They include architecture-dependent options from ARCH_FLAGS, header searching options from ROOT_CFLAGS and additional flags directly from any_morebuild_cflags or any_morebuild_cxxflags.

Involved variables: ROOT, SUBFS, ARCH_FLAGS, ROOT_CFLAGS

Involved options: any_arch_flags, any_morebuild_cflags, any_morebuild_cxxflags, any_program_prefix, any_program_prefix_list

ENGINE_LDFLAGS

Link-time default flags.
These options to compiler at link stage are needed for correct build in any environment. They include architecture-dependent options from ARCH_LDFLAGS, library searching options from ROOT_LDFLAGS and additional flags directly from any_morebuild_ldflags.

Involved variables: ROOT, SUBFS, ARCH_LDFLAGS, ROOT_LDFLAGS

Involved options: any_arch_ldflags, any_morebuild_ldflags, any_program_prefix, any_program_prefix_list

ENVDUMP

Dump with variables of current shell.
Opposed to DUMP, the given file contains only variables.

Involved variables: LOGDIR, P

FLAVOUR

Notation for build in one of variations.
The variable means the package is built in one of several possible configurations, and there can be set up only one of them at the same time. For example, TLS protocol in a package is implemented with nss, openssl or gnutls. FLAVOUR differs from BPN:

BPN declares several subpackages, which are produced altogether from the build.

FLAVOUR points to a variation of single package.

By default variable is not set. When FLAVOUR is not empty, it is appended to the name of the file with a package. For example, with flavour gui package hello-world-1.0 will be packed into archive hello-world-gui-1.0.txz. The variable is not appended to the name, used by package manager, thus different flavours are the same package for it. But the value of FLAVOUR may be shown in package meta-information: that depends on module implementation, which creates binary package.

HDEPEND

Build time dependencies of current package, needed to be installed in host.
Format of entries is the same as for DEPEND, see its description.

Build-time dependencies may provide not only includes, libraries and another readable files, which is possible to reflect inside ROOT. Dependencies may be required for executable files. They are build tools like make(1) and its numerous analogues (cmake, qmake), documentation generators, parsers of different data formats. Such applications could not be reflected into separate directory, like it happens for packages from DEPEND. They need proper installation into main filesystem.

Cross-compilation enlarges the list of host dependencies. If some binary file is generated during the build and then process tries to execute it, the scheme cannot be done because of different target architecture of the binary. Such files should be compiled for host architecture beforehand and installed additionally.

Related variables: DEPEND, RDEPEND

HOSTARCH

CPU architecture of host: platform, hosting the build.

Involved options: any_host_arch

HOST_CC

C compiler string in host environment.
Native compilation does not need the HOST* series. With cross-compilation the host toolchain is needed separately from main toolchain variables (CC, CXX, CCLD, CXXLD, CPP).

The variable preserves outer value.

Involved options: any_tch_host_cc

HOST_CCLD

String to call compiler at link stage in host environment.
If not set up explicitly, it is assigned the value of HOST_CC.

The variable preserves outer value.

Involved options: any_tch_host_ccld

HOST_CPP

String to call preprocessor in host environment.
Normally, equals to generic C compiler with -E option.

The variable preserves outer value.

Involved options: any_tch_host_cc

HOST_CXX

C++ compiler string in host environment.

The variable preserves outer value.

Involved options: any_tch_host_cxx

HOST_CXXLD

String to call compiler at link stage for C++ in host environment.
If not set up explicitly, it is assigned the value of HOST_CXX.

The variable preserves outer value.

Involved options: any_tch_host_cxxld

IMGDIR

Base directory for packages, installed as build dependencies for any system.
It contains subdirectories, named after packages. Usually this directory is not used by itself. With the dir it is possible to access directly the files of other packages.

Involved variables: BASEDIR, APROFILE

Involved options: any_write_root

INNER_VERSION

Inner package version.
Represents package state, specific for the project, for example, quantity of local fixes.
The variable is empty by default, and inner version is defined whether from saved file inner_version, whether is calculated on base of sources. See section Inner versions in any-build(7) and fetch_inner_version(3).

KEYWORDS

List of words, describing supported configuration for a current package.
The list has the following format:

KEYWORDS="~nottested ~badarch itworked goodone ..."

The words with ~ at the beginning are called masking. They mark the configuration, for which the package does not work. If there is entry ~badword in KEYWORDS, and configuration AUSE has word badword, then the build of a package will be interrupted with status SKIP.

The words without modificators at the beginning are called restricting. They mean the package works only for given configuration, with following rules.

If at least one restricting word from KEYWORDS is met in AUSE, the build is allowed. For the example above the words are itworked and goodone.

If at least on restricting word from KEYWORDS is the value of variables:

ANYARCH

ANYARCHMODE

ANYOS

ANYARCHCAP

ANYARCHENDIAN,

then build is allowed.

Special case is architecture-independent mode, when at least one from the variables ANYARCH, ANYARCHMODE, ANYOS equals all. In that instance the build is allowed disregarding restricting words. Along with that architecture-independent mode does not cancel the effect of masking words like ~badword - if it has been met in configuration, the build is interrupted.

If none of the conditions above has not been met in the presence of restricting words, the build is interrupted with status SKIP.

KEYWORDS may have at the same time both masking and restricting words in arbitrary order. The described check is done by method keywords_check(3).

LD, CXXLD, RANLIB, STRIP, OBJDUMP, AR, NM

Variables with accordance to toolchain.
These variables are set, basing on compiler from CC (from CXX for CXXLD). They are initialised in some module for toolchain support, for example, in tch or plaincc.

Involved variables: CC, CXX

Available with toolchain modules (tch, plaincc)

LINGUAS

Codes of used languages.
It is possible to assign with the variable which languages from the localisation of a package are actual in the project. Languages, missing in LINGUAS, may be deleted.

Involved options: any_program_linguas

LOG

Log file with build process of current package.

Involved variables: LOGDIR, P

LOGDIR

Directory with all log files for current APROFILE.

Involved variables: BASEDIR, APROFILE

Involved options: any_write_root

MAKEOPTS

The variable with flags for make(1) program.
The most frequent usage is passing of options for parallel make launch.

The variable preserves outer value.

Involved options: any_make_opts

METADIR

Root directory with various metainformation for the project.
The example is etalon data for regression testing or sanity checkers inside packages.

Involved options: any_meta_dir

Involved variables: BASEDIR

MINTDIR

Directory with etalon data for a current package.
Sanity checkers search for etalon data inside this dir to compare them with current results. Each checker uses its own data format for comparisons. Checkers provide dedicated procedures to store data into MINTDIR as etalon one.
MINTDIR is different for various values of APROFILE.

Involved variables: METADIR, APROFILE, P

Related variables: MINTNEUTRALDIR

MINTNEUTRALDIR

Directory with APROFILE-independent etalon data for a current package.
Sanity checkers search for etalon data inside this dir after they were not found inside MINTDIR. Procedures for storage of etalon data usually do not write into this directory, as it is more universal, then MINTDIR. If it is known that data is generic and applicable for various APROFILE, it should be saved into MINTNEUTRALDIR manually.

Involved variables: METADIR, P

Related variables: MINTDIR

MY_P

Name of original sources.
Defaults to P. Variable should be changed, when the package name P, taken from distro project, mismatches the name of source archive from the author.

Involved variables: P

MY_PD

Name of development sources.
Defaults to P. Variable should be changed, when the package name P, taken from distro project, mismatches the name of repository, where given sources are developed.

Involved variables: P

OPT_FLAGS

Flags for compiler optimisation. That options to compiler should be used for performance improvement. The correctness of the code for the platform cannot rely on that options. If some options are known to be needed in order for code correctness, they should be put into ARCH_FLAGS instead.

Related variables: ARCH_FLAGS

Involved options: any_opt_flags

OPT_LDFLAGS

Flags for linker optimisation. See option above.

Related variables: ARCH_LDFLAGS

Involved options: any_opt_ldflags

P

Full name of a package in the project.
That is main id of a package in build environment:

a package is named so in command line for tools of any (for example, for any-do(1));

a package is named so in ports/list/ lists;

the name is included into dir with anybuild DISTDIR;

the name is inside essential paths $S, $D.

Involved options: rdd_atom_id

PACKDIR

Directory with ready binary package archives.
The result of building individual source packages are binary packages, installable on machine. They are stored here.

If the project after the build of some package set prescribes the creation of consolidated result, for example, of operating system installation image, then such results will reside in another directory, RELEASEDIR.

Involved variables: BASEDIR, APROFILE

Involved options: any_write_root

Related variables: RELEASEDIR

PATCHDIR

Directory with patches for current package.
Given directory is created inside temporary directory, aimed for the build. The patches are copied here from one of the sources by fetch_gen_patches(3) method at src_fetch(3) build stage. Sources of patches search for copying into PATCHDIR:

DISTDIR/patch/; example: ports/packages/package-name-1.2.3/patch/
ports/patch/package-name-1.2.3/

One should not access directly the directories above within anybuild.

Involved variables: DISTDIR, BASEDIR, P

Involved options: any_static_patch_dir, any_write_root

Related variables: PATCHLIST

PATCHLIST

List of patches to apply for current package.
Empty by default. In that case all patches from PATCHDIR are applied (without subdirectories). When this variable is set up, only listed patches are applied. The search for them goes inside PATCHDIR as well.

Related variables: PATCHDIR

PKG_ARCHITECTURE

Architecture of current package, suitable for all binary formats (such as deb or txz). Unlike ANYARCH, the variable describes only separate package, not the entire build session. The variable is also used for binary archives only.

PLAIN_CC

Executable file of C compiler.

The variable preserves outer value.

Involved options: any_tch_cc

PLAIN_CCLD

Executable file of C compiler, called at linking.
If not set up explicitly, it is assigned the value of PLAIN_CC.

The variable preserves outer value.

Involved options: any_tch_ccld

PLAIN_CPP

String to call preprocessor.
If not set up explicitly, it is assigned the value of PLAIN_CC with -E option.

The variable preserves outer value.

Involved options: any_tch_cc

PLAIN_CXX

Executable file of C++ compiler.

The variable preserves outer value.

Involved options: any_tch_cxx

PLAIN_CXXLD

Executable file of C++ compiler, called at linking.
If not set up explicitly, it is assigned the value of PLAIN_CXX.

The variable preserves outer value.

Involved options: any_tch_cxxld

PN

Package name without version.
It is extracted automatically from P.

Involved variables: P

PREFIX

Default prefix for package files layout.
When PREFIX is set to /usr, package files will reside in /usr/lib/, /usr/bin/, /usr/share/ and so on. Note some files normally should not be under PREFIX, such as from /etc/ or /var/.

The variable preserves outer value.

Involved options: any_program_prefix, any_program_prefix_list

PREFIX_LIST

List of prefixes, used in the project.
Some packages may be configured with non-default prefix. For example, essential software is configured with prefix / instead of /usr. If access to the files of packages with non-standard prefix is needed during further building of other packages, then non-standard should be added to overall list through any_program_prefix_list option. PREFIX_LIST will contain new value, and build system will consider paths with new prefix in its inner mechanics.

Involved variables: SUBFS

Involved options: any_program_prefix, any_program_prefix_list

PV

Package version.
It is extracted automatically from P. If a package does not contain version, the variable is initialised with 0.0 value.

Involved variables: P

RDEPEND

Run time dependencies of current package.
Modules for package formats use it to generate dependencies inside binary archive. The format of entries in common case can be arbitrary. The variable is not used at build stage.

If RDEPEND is empty, package modules will use DEPEND as a source for run-time dependencies. That is simplification for the case when DEPEND and RDEPEND are the same, so no need to fill in two variables. To prevent that behaviour, assign RDEPEND space value: RDEPEND=' '


The build system performs control of binary compatibility: during generation of run-time dependencies the values from RDEPEND are modified in a way to consider the context of real build, which has influenced the package. The modification takes place with conditions:

-

RDEPEND has the same format, as DEPEND. If RDEPEND has another syntax for ranges or names, any can not modify these entries.

-

The mode autobpi is off. See its description in block with BPI.

With conditions above kept, the following modification is performed:

for all entries from RDEPEND, used during the build and present in DEPEND, the engine add lower minimal boundary in form >=.

As a result, binary package can not be used with packages with versions lower, then versions of packages, used during its actual build. That is pessimistic assumption about breakage of binary compatibility after any possible change of version.
To regulate the change of binary interface explicitly, use autobpi mode and the variable BPI.

Related variables: DEPEND, HDEPEND, BPI

RELEASE

Short global id of the current release.
Inner version inside binary package is prepended with that value. It is the way to mark the buildage of a package in the environment of distro release of specific global version: distro2, distro3. If the version of source package has not been changed, binary archive for the work inside distro2 will definitely differ from the variant for distro3.

If it is required to set up release id for the series of packages, it is advisable to assign global option any_release_id.

The variable preserves outer value.

Involved options: any_release_id

RELEASEDIR

Directory for release files.
The results of entire project build are kept here, such as installation images. Each project defines individually what are its release results.

Involved options: any_release_dir

RELEASE_VERSION

Complete version of the current release.
Exact id with complete version for the entire distro release.

Involved options: any_release_version

ROOT

Directory with build context for current package.

Here the artificial filesystem resides, which is provided for the build of the current package. It is formed from packages, declared in DEPEND and actually found inside IMGDIR. The following files and directories of a package are mirrored to ROOT:

entire PREFIX/include/

entire PREFIX/lib/

non-binary scripts PREFIX/bin/*-config, PREFIX/bin/*-config-*

ROOT is built separately for each package. So build contexts of different packages do not interfere. ROOT is removed and created anew before each build.

Majority of files are mirrored to ROOT with symbolic links. It is fast and they do not occupy disk space. Links are relative, so if a link is done within chroot, it will work outside as well.
Some of the files are hard-copied. That is due to necessity to edit the content of the files so that data inside will contain correct paths, which match the new dir. By default, .pc files are copied and edited.

The module staticdeproot provides another build mode. To turn it on, set up option any_static_root=1. In the mode staticdeproot ROOT is static directory, common for all packages with current APROFILE. It is not removed dynamically. All packages are placed there, which were built in the local working directory with current APROFILE. Build context in the mode is not controlled explicitly. It depends on the things, built before. Along with that all available packages at once are seen during the build. Given mode is used to gather information about build dependencies by the module builddep(7). It is possible to apply it, if dynamic handling of dependencies is unavailable by some reasons.

See any-conf(7), options with prefix any_root, for additional settings of:

which paths inside packages are reflecting to ROOT

which executable files are reflecting to ROOT

which files are hard-copied instead of symlinking

The variable preserves outer value.

Involved variables: CONTEXTDIR, P

Involved options: any_static_root

Related options: entire section core_root inside any.conf

ROOT_CFLAGS

Strings for compiler to point to header files inside ROOT directory.

Involved variables: ROOT, SUBFS

Involved options: any_program_prefix, any_program_prefix_list

ROOT_DIRS

Space separated list with directories for reflection into ROOT. Paths are absolute.
There are those files in given directories, which would be used by another packages during their build.

Involved variables: ROOT, SUBFS

Involved options: any_program_prefix, any_program_prefix_list

ROOT_LDFLAGS

Strings for compiler to point to libraries inside ROOT directory.

Involved variables: ROOT, SUBFS

Involved options: any_program_prefix, any_program_prefix_list

S

Directory for the build of the current package.
The package sources are copied here, and the build goes here. This is common variable to handle intermediate files in anybuild.
src_config(3) expects on being inside the S at the start. Change of the current directory to S usually is done inside src_fetch(3).

Involved variables: WORKDIR, P

SRC_URI

Single adress or list of adresses (paths, URLs) to fetch the package sources from.

SUBFS

Additional subdirectory in filesystem.
It is accounted automatically inside path variables ROOT_* and PREFIX_LIST. The variable is used to locate some set of packages in their own subroot, like /opt/out/bin/, /opt/out/lib/, /opt/out/share/ and so on.

The variable preserves outer value.

Involved options: any_program_subfs

T

Temporary directory for current package.
Used to keep all intermediate files, which are created by the engine itself and not by the build of source files, belonging to the package.
As methods can be called from arbitrary point, it is recommended to create T explicitly before accessing it. The dir should not be deleted in the middle of the build between methods of map.

Involved variables: TMPDIR, P

TMPDIR

Directory for temporary files, common for all packages in current profile APROFILE.

Involved variables: BASEDIR, APROFILE

Involved options: any_write_root

USE

Variable with use flags for package tuning.

Use flags are kept in space separated unordered list. These flags are much like data words in AUSE, but they concern functions inside package, while AUSE keeps global settings, concerning distro as a whole. Use flags allow to configure and build package with difference, depending on status of some flag, whether set or not, and without manually editing the anybuild. use series of methods is applied for them. Some code or option inside anybuild is put under condition, calculated with use flags. The flags can be switched with cmd options or config files.

USE flags are calculated from the composite option use_all and options like use_flag, where flag is individual.
Option for overall use list has the following format:
use_all="one two three -four ..."
When flag is listed, it is added to USE. When it is listed with - at the beginning, as flag four in example above, it is deleted from USE.

Individual flags are in the format:
use_flag=1 use_moreflag=0
Flag with value 1 is added to USE. Flag with 0 is deleted.

Involved options: use_all, use_* series

UTILROOT

Utility to create root-owned materials, when running as general user. Used at package creation, where files should be owned by root inside archives.

WORKDIR

Directory for build files of all packages in current profile APROFILE.
Usually it doesn't contain files on itself and serves as a basedir for S. It can be useful to access the build files of neighbour non-current package.

Involved variables: BASEDIR, APROFILE

Involved options: any_write_root

The following methods are always provided by the engine, disregarding used modules. Their definition resides at any/corelib/interfaces.sh file.

alog message

Print the message to the stdout.
If an argument is quoted, it may contain several lines.

ause word

Return 0, if given word word is present in current configuration and is contained in AUSE. Return 1 otherwise. Method does not print any output.

ause_enable word text

If given word word is present in current configuration (is contained in AUSE), print text to stdout.
It is recommended to quote the second argument text.

ause_notenable word text

If given word word is not present in current configuration (is absent in AUSE), print text to stdout.
It is recommended to quote the second argument text.

available prog

If the built package is deployed inside working directory with a name, matching the template ^prog, print prog to stdout.
The package presence is checked inside directory IMGDIR.

awarn message

Print the message to the stderr.
If an argument is quoted, it may contain several lines.

die message

Print the message to the stderr and exit from current process with code 1.
Used as error handler before termination.

dielater message

Print the message to the stderr and set up global status FAIL. After the status check in method status_check(3) the process will be terminated.
Used for delayed exit, when some code execution is needed before process termination.

directbuild

Return 0, if the process was launched directly from the anybuild, without any-do(1). Return 1 otherwise.

dopatch patchfile

Apply diff from file patchfile to sources in current directory and leave the comment in stdout. Apply patch or series of patches to the sources in current directory.
patchobject may be a file or a directory. If a file is given, it is applied as plain patch. If a directory is given, the patches inside are applied. The content of nested subdirectories is not used. See patchlist description about search for patches in a directory.

If the path to patchobject is relative, a file or a directory is checked in the following locations in priority order:

./patchobject

PATCHDIR/patchobject

S/patchobject

dumpbuild

Auxiliary script to initialise the build environment in current process.
It helps to launch anybuilds directly as standalone scripts, without any-do(1).

forcetobuild

Change current directory to S. If it does not exist, create it first.

getsrc packname [path] [PATCHLIST="one two ..."]

Fetch and prepare sources for package packname at location [path]. If there is only one argument and path is not given, sources are fetched into current_directory/packname/.
Methods src_fetch(3) and src_prepare(3) are executed for sources of package packname, taken from its build (not from the build of a current package).
If there are patches for packname, the directory with them will be located in S/patch. That gives opportunity to apply patches of another package manually.
getsrc ignores the variable PATCHLIST, because it relates to a current package and not to the packname. It is possible to set up explicitly the value of PATCHLIST for getsrc as an option instead of environment variable:

getsrc package-1.2.3 PATCHLIST="subdir/fix.patch subdir/another.patch"

inherit package

Load the anybuild file of given package to current process.

the variables will become equal to values from another package;

the functions will appear, implemented in another package.

One of the usages is creation of auxiliary packages-duplicates to slice circle dependencies.

linkdir fromdir destdir [extenstion]

Make relative symbolic links for all files and symbolic links, located in directory fromdir. Links will be located in directory destdir with the same subdirs structure, found within fromdir. Subdirs inside destdir are created, not imitated with links.

Optional argument extension contains the file criterion: the links will be created only for files with names, ending with extension.

linkfile fromfile destfile

Make relative link, which points to fromfile and is located at destfile.

map_direct

The launch of actual build actions in case of direct work from anybuild, without any-do(1).

nonfail

Return 0.
It is used as a handler for methods with non-null exit code, which are known to exit correctly.

rmbuild

Remove directory with build materials of a current package from WORKDIR.
That directory contains sources and object files.

patchlist [dir]

List all non-hidden files in a directory.
If argument is not set, files are listed from PATCHDIR.
Method does not list content of nested directories. So patches in PATCHDIR/subdir are not printed.

pkgbase

input |  pkgbase [packname1 ... packnameN]

Read package names and print their names without version to stdout, each on new line.
The rest behaviour is analogical to pkgbin, see its description.

pkgbin

input |  pkgbin [packname1 ... packnameN]

Read package names and print names of their installable binary archives to stdout, each on new line.
Method reads input data from stdin and then from arguments. Multiline input is read from stdin. In absence of any outer input data, the method prints binary packages, created by current P package. The format of binary archives is defined by configuration.

Which binary packages are produced by given name is defined by BPN or BP variables in build file of each package with that name. For each given package the method fetch_inner_version(3) is called. If package format writes inner version into binary archive name, the method output changes after the change of package inner version.
Method takes into account KEYWORDS checking: if a package is missed for current configuration, there will be no output for it.

pkgname

input |  pkgname [packname1 ... packnameN]

Read package names and print full names with version of their installable binary packages to stdout, each on new line.
The rest behaviour is analogical to pkgbin, see its description.

rootlink arg

Create symlink in ROOT/arg, pointing to D/arg.
Directories are handled, as described for linkdir method, plain files as described for linkfile method.

skip message

Print the message to the stderr and exit from current process with status SKIP.
The exit code is 13.

skiplater message

Print the message to the stderr and set up global status SKIP. After the status check in method status_check(3) the process will be terminated.
Used for delayed exit, when some code execution is needed before process termination.

tobuild

Change current directory to S, if it exists.

unlinkcopy

input |  unlinkcopy

The method reads from stdin. If read string is a symbolic link, it replaces the link with real copy of file. Copied files are printed to stdout.

use flag

Return 0, if given flag presents in USE. Return 1 otherwise. Method does not print any output.

use_enable flag text

If given flag presents in USE, print the text to stdout.
Second argument text is recommended to put into quotes.

use_notenable flag text

If given flag is absent in USE, print the text to stdout.
Second argument text is recommended to put into quotes.

any(1), any-build(7), any-conf(7), rdd(1), any-dev(7)