any-api – interface for anybuilds, provided by any(1) engine.

Description

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

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, modules are picked up according to data words, as described in section Modular code inclusion of any-do(1). The input data for the engine are variables from config files, constructed by rdd(1).

Shell variables, composing anybuild API, are in all-capital letters. Methods of any 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). Anybuilds also 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 outside of the engine.

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. The example of such module is aplain, which provides interfaces for typical build sequence:

    ./configure
    make
    make install
Examples of other modules 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.

API variables

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

When current variable is constructed from other API variables, they are listed as involved for that variable. Likewise mentioned the options from rdd(1) config files.
When option or variable influences on some behaviour, closely related to the described variable, it is listed as related in description. When variable can be set up directly with outer environment shell variable (not with option from config file), it is stated as preserves the outer value.
When variable is available only with some data word or with some method call, it is stated as well.

ANYAPI
Version of any-api.
The value is integer unsigned number. It can be used to check compatibility or requirements of some module.

ANYARCH
Architecture of built binaries.
The original meaning of the variable is CPU architecture. However, the distro project may put another area into meaning of this variable.
If not set up explicitly, it is assigned the HOSTARCH value.
Values of this variable are checked by KEYWORDS mechanism.

The variable preserves outer value.
Involved variables: HOSTARCH
Involved options: any_arch
Related variables: KEYWORDS

ANYARCHCAP
Capacity of built binaries.
32-bit or 64-bit in most cases. Specialized variable allows to use KEYWORDS for capacity as well.
Values of this variable are checked by KEYWORDS mechanism.

The variable preserves outer value.
Involved options: any_arch_capacity
Related variables: KEYWORDS

ANYARCHENDIAN
The endianness of built binaries.
Little vs big endian order of bytes inside data words.
Values of this variable are checked by KEYWORDS mechanism.

The variable preserves outer value.
Involved options: any_arch_endian
Related variables: KEYWORDS

ANYARCHMODE
Architecture family of built binaries.
Such family is some generalized class, which includes several more concrete architecture values. The CPU power series can be an example of architecture family for power7, power8 and power9 processors.
Values of this variable are checked by KEYWORDS mechanism.

The variable preserves outer value.
Involved options: any_arch_family
Related variables: KEYWORDS

ANYDEVSRCDIR
Directory for development sources, fetched from version control systems.
These sources are expected to contain changes, developed locally. They can be copied directly over original ones or can be transformed into patches.

Involved variables: BASEDIR
Involved options: any_dev_src_dir

ANYOS
The operation system for built binaries.
Values of this variable are checked by KEYWORDS mechanism.

The variable preserves outer value.
Involved options: any_os
Related variables: KEYWORDS

ANYSRCDIR
Directory with original source archives (tarballs) or entire source directories.
These sources are used unchanged.

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. If the user decides that some data word leads to change of ABI or some other effect, requiring separate build tree, he changes one or several of the options above under that data section in rdd(1) configuration file.
For example, data words cap32 and cap64 mean different capacity for binary executables and incompatibility between them. In that case cap32 may cause altered APROFILE like arch_32, assuming arch is the main build tree.

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. Normally they are already contained in more generic options ENGINE_*, 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. Normally they are already contained in more generic options ENGINE_*, but direct access can be useful as well.

The variable preserves outer value.
Involved options: any_arch_ldflags

AUSE
Variable with all used data words in current launch.
It contains data words without repeats as space separated list in the order of their inclusion by rdd(1), the most right one is included first and has the highest priority. Variable is used at including shell modules, which are found by data words. It is used in ause series of interface methods for anybuilds, which check project-level conditions. ause methods allow to build packages differently, depending on some global conditions, stored in distro project configuration.

Involved options: rdd_prf_all

BASEDIR
Root of the working directory.
In case of containerised work, this is 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 multiple binary packages are described in BPN.

Related variables: P, BPN, BPV

BPI
Version of binary package interface.
Defaults to PV. When package packA is built against package packB with BPI equal to 1.2.3, the metainformation of packA contains the record >=packB-1.2.3 in dependencies.
The variable may be used to soften the dependency requirements. 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.
If set to non-default value, BPI 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.

BPN
Plain name without version for binary package.
Defaults to PN. That name will be seen to package manager at run-time after installation of binary archive.

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.
Creation of several binary packages packfullname1, ...packfullnameN requires directories IMGDIR/packfullname1, ...IMGDIR/packfullnameN, each one containing files for corresponging package. Files are copied from D to IMGDIR/packfullnameN by image_split_pack(3) method or manually.
When single binary package is produced, its content is searched in IMGDIR/packfullname and then in D. So for a single resulting binary archive its files may be just left in D without additional copy somewhere else.

It is highly discouraged to set up any of BP, BPN, BPV variables inside method, which is not called automatically at the top of the build. That will lead to incorrect names of binary packages while their listing with pkgbin or 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
Upstream version inside binary package.
Defaults to PV. This part of version reflects number inside P. It does not include inner version, which is calculated automatically with 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 wrapper 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 wrapper variable equals to PLAIN_CC.

The variable preserves outer value.
Involved variables: PLAIN_CC

CONFIGCACHE
File with cache for configuration system of current package.
It is gathered from data, prepared beforehand in some directory. The location of the data and methods, working with this file, depend on module, which handles configuration. For aplain module these are APLAIN_SRCDIR directory and aplain_config_cache_* methods.
Configuration cache is used mainly for cross-compilation to give configure system answers for tests which it cannot detect on host system. It can be used also to reduce configuration time (very slightly).

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 wrapper 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 wrapper 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 wrapper 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 are the list of entries, separated by spaces or new lines. Single entry is the range of allowed package 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.


Versions are compared as version strings by algorithm of sort -V. Inner versions, kept by INNER_VERSION or calculated automatically, do not participate in comparison.
Available packages are checked as installed each into its own separate directory inside IMGDIR. Basename directory with installation must be named as the checked package.
Dependencies from DEPEND are checked during the build with any(1) and may be different from run-time dependencies, which are used by package managers.

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, this dir contains all files for creation of binary package, such as postinstall scripts. It can optionally keep patches as well.

Involved options: any_rdd_root, rdd_atom_path
Involved variables: P

DUMP
File with entire shell context for current package.
This dump file is standalone shell script, which makes available all methods and variables of the engine and current package. Variables, derived from rdd(1) options, are inserted at its beginning. Dump does not inline used shell libraries: for correct work of dump they must be present as separate files at their paths, as they have been at moment of dump creation.

The dump is used when data of the package is needed outside of that package building. Any process can include (source) the dump and get all values of that package, such as name, version or customized values of other variables. As including the dump changes the variables of current process, it should be done in sub-shell for correct further work.
The example of dump usage is dependencies handling, when dump for each used package is sourced and pkg_root(3) is executed.

Involved options: any_dump, rdd_atom_dumpdir

D
Directory with installed files of the current package.
It serves as DESTDIR for make install inside src_install(3) method. It is used by many map methods also.
Each package is installed to dedicated directory. That allows to include together files of varying set of packages easily and fast. This property is also used to create separate installable archives.

Involved variables: IMGDIR, P

ENGINE_CFLAGS, ENGINE_CXXFLAGS
Compile-time default flags inside any.
The options to compiler, containing everything engine-related to do the correct build. 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 inside any.
The options to compiler at link stage, containing everything engine-related to do the correct build. 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
File with exported shell variables, available for child processes.

Involved variables: LOGDIR, P

FLAVOUR
One of possible modifications of a package.
By default variable is not set. When FLAVOUR is not empty, it is appended to the package name part in the binary archive. 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, written to meta-information, intended for package manager, thus different flavours are the same package for it.
This variable is used, when package may produce alternative binaries, and only one set of them may be normally installed. That is unlike several entries in BPN, which show several subpackages, installable all at once.

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 include, library and another readable files, but also executable ones. These executables are used for build tasks: tools like make(1), documentation generators, parsers of different data formats. The variable keeps the packages, which are required in host for that.

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

Related variables: DEPEND, RDEPEND

HOSTARCH
Architecture of host run-time environment.

The variable preserves outer value.
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.

The variable preserves outer value.
Involved options: any_tch_host_ccld

HOST_CPP
String to call preprocessor in host environment.
Normally, equal 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.

The variable preserves outer value.
Involved options: any_tch_host_cxxld

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

Involved variables: BASEDIR, APROFILE
Involved options: any_write_root

INNER_VERSION
Variable with inner version of current package.
Not set by default. In that case inner version of a package is calculated automatically inside fetch_inner_version(3). Package-specific variables, relating inner version, have higher priority over this generic variant.

KEYWORDS
List of words, which describe supported configuration for the current package.
The list has the following format:
KEYWORDS="~nottested ~badarch itworked goodone ..."
The words with ~ at the beginning contain flags, which mark unsupported conditions. Flag may be any word from AUSE. If any of flags, marked with ~, is met in current AUSE, status_set_skip method is called and build recieves SKIP status. At the next call of status_check(3) the build will be interrupted (and usually status_check is called shortly after). Putting the ~ word in KEYWORDS is also called masking the package for that word.

The words without modificators at the beginning represent restricting set of flags, which mark the working configuration. That means package works only when at least one of given restricting conditions is met. If none of given flags are met between words of AUSE or as a value of ANYARCH, ANYARCHMODE, ANYOS, ANYARCHCAP, ANYARCHENDIAN variables, build is marked as skipped. Use this form with care, as it requires to explicitly mark the working configuration instead of separating the unneeded variants with known troubles.

If any of ANYARCH, ANYARCHMODE, ANYOS variables contains the value all, the build is passed, even if restricting set of flags has not been met. With the value all the build is still skipped, if given ~words have been met in AUSE.
Masking and restricting words can be listed in any order inside the variable.

Check by KEYWORDS is done within keywords_check method. Default any.conf has it in rdd_map_autopre, so check is done as indented. It is possible to turn off the check by this mechanism with removing method call from map.

LD, LXX, RANLIB, STRIP, OBJDUMP, AR
Variables with accordance to toolchain.
These variables are set automatically basing on CC variable (CXX for LXX). The values always accord to given working compiler. As such extraction needs binary execution, they are initialised with data word tch and not at engine core. Thus heavy calls to compiler may be avoided by not including tch in time-demanding launches. Execution of outer files at stage of variables constructing should be reduced as much as possible.

Involved variables: CC, CXX
Available with data word: tch

LINGUAS
Codes of used languages.
Variable keeps list of needed languages, when localisation is in use. Packages may contain multilingual materials, such as translated message texts. With LINGUAS it is possible to preserve only needed ones and remove all the rest.

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 of such information is etalon data for sanity checkers.

Involved options: any_meta_dir
Involved variables: BASEDIR

MINTDIR
Directory with etalon data for current package.
Sanity checkers search for correct samples inside this dir to compare them with freshly generated variants. Each checker uses its own file layout for results and etalons. Checkers may save their fresh data into MINTDIR by demand.
MINTDIR is different for various values of APROFILE.

Involved variables: METADIR, APROFILE, P
Related variables: MINTNEUTRALDIR

MINTNEUTRALDIR
Directory with APROFILE-independent etalon data for current package.
Sanity checkers search for correct samples inside this dir after they are missing in the MINTDIR. Checkers do not save files here on their own, the data considered as universal is put here by the user. It makes sense to keep data for majority of APROFILEs in MINTNEUTRALDIR and leave specific flavours in their according MINTDIRs.

Involved variables: METADIR, P
Related variables: MINTDIR

MY_P
Name of original sources.
Defaults to P. It is used when package name inside the distro project and sources of package at its author's domain are named differently.

Involved variables: P

MY_PD
Name of development sources.
Defaults to P. It is used when development sources are named differently from package name inside the distro project.

Involved variables: P

P
Full name of the package.
It comes from rdd(1) and its variable rdd_atom_id.

Involved options: rdd_atom_id

PACKDIR
Directory with binary package archives, ready for use on target system.

Involved variables: BASEDIR, APROFILE
Involved options: any_write_root

PATCHDIR
Directory with patches for current package.
Patches may get here from different places: they may be generated from development sources by fetch_gen_patches(3) at src_fetch(3) stage, copied from local place for preserved patches (any_static_patch_dir option points there), or copied from DISTDIR. Patches may be dropped to this dir directly as well.

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. When this variable is set up, it contains the exact list of patches inside PATCHDIR, needed to apply. When the variable is empty, all patches from PATCHDIR are taken (without its subdirectories).

Related variables: PATCHDIR

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.
Normally, equal to generic C compiler.

The variable preserves outer value.
Involved options: any_tch_ccld

PLAIN_CPP
String to call preprocessor.
Normally, equal to generic C compiler 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.
Normally, equal to generic C++ compiler.

The variable preserves outer value.
Involved options: any_tch_cxxld

PN
Package name.
It is extracted automatically from P.

Involved variables: P

PREFIX
Default prefix value for package files location.
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 of interest.
These are all prefixes, which may contain files of packages according to current configuration.

Involved variables: SUBFS
Involved options: any_program_prefix, any_program_prefix_list

PV
Package version.
It is extracted automatically from P. If package does not contain version, the variable is assigned 0.0 value.

Involved variables: P

RDEPEND
Run time dependencies of current package.
The variable is not used directly. If it is set, modules for package managers use it for dependencies inside binary archive. The format of entries can be arbitrary.

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 assign two variables. To prevent that behaviour, assign RDEPEND space value: RDEPEND=' '
If RDEPEND follows the same entry format, as DEPEND, any takes into account the actual versions of packages, which were used during the build of the current one. For all entries from RDEPEND, which were used during the build, engine adds the lower minimal boundary in the form of >= to run-time dependencies. So resulting binary archive cannot be used with packages of lower versions, then ones it was built with.

Related variables: DEPEND, HDEPEND

RELEASE
String id of the current release.
It is used for binary packages to identify the release series they belong to.

The variable preserves outer value.
Involved options: any_release_id

RELEASEDIR
Directory to keep release files.
This is used to store results of entire project build.

Involved options: any_release_dir

RELEASE_VERSION
String version for the current release.
It contains numeric exact id of the release.

Involved options: any_release_version

ROOT
Directory with build context for current package.

The whole filesystem, intended for use by current package, resides here. It is formed from selected files of other packages, installed inside IMGDIR each to its own separate directory. 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-*


By default, the packages are considered as used by the current one, if they are ordered by DEPEND variable inside current anybuild.
When data word staticdeproot is used during the building, ROOT is populated with all packages, built and installed during the session with that word. Thus entire package pool is visible to new packages. This mode is used, when information about build dependencies is collected. It can be used in other cases too, when handling of dependencies is not applicable.

Majority of files are mirrored to ROOT with symbolic links, which is fast and space efficient. Links are relative, so if a link is done within chroot, it will remain available outside.
Some of the files are hard-copied, when new environment is prepared. That is due to necessity to edit the content of the files so that data inside will contain correct paths to dirs in new place. By default, .pc files are copied and edited.

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 of interest inside ROOT.
These directories contain all files of packages in normal layout. Paths are absolute.

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 to build current package.
The package sources are copied and prepared here, then build starts. 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 is done inside src_fetch(3) usually.

Involved variables: WORKDIR, P

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

SUBFS
Additional path for separate subtrees in filesystem.
It is accounted automatically inside path variables ROOT_* and PREFIX_LIST. 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 before access to it at the beginning of each method, unless some other method, coupled with the current one, has done that already. 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.

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 package-level specific, while AUSE is about distro-level. Use flags allow to configure and build package differently, when some use flag is set or not, and without manually editing the anybuild each time. To achieve this, use series of methods is applied. Some code or option inside anybuild is put under condition, calculated with use flags. As these flags can be set up with outer command line options, user gets the possibility to tune the inside of the build.

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

API core methods

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

alog message
Print the message to the stdout.
Argument is single text, may be multi-lined.

ause word
Return 0, if given word is used in current launch and presents in AUSE. Return 1 otherwise. Method does not print any output.

ause_enable word text
If given word is used in current launch and presents in AUSE, print the text to stdout.
Second argument text is recommended to put into quotes.

ause_notenable word text
If given word is not used in current launch and is absent in AUSE, print the text to stdout.
Second argument text is recommended to put into quotes.

available prog
If any package with the name matching the template ^prog is present in IMGDIR, print prog to stdout.

awarn message
Print the message to the stderr.
Argument is single text, may be multi-lined.

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

dielater message
Print the message to the stderr and set error status for later check with method status_check(3).
It is used for delayed termination when some part of code should be done before the exit.

dopatch patchfile
Apply diff from file patchfile to sources in current directory and leave the comment in stdout.

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

getsrc packname [path]
Fetch and prepare sources for package packname at location [path]. If second argument [path] is empty, sources are fetched into current_directory/packname/.
Inside getsrc the methods src_fetch(3) and src_prepare(3) are called with settings for given package packname. All specific actions for source handling, written in the build of packname, are taken into account.

inherit package
Load the build file of given package to current shell.
Method may be called by some sub-package with deviations from the main one to exclude code duplication.

linkdir fromdir destdir [extenstion]
Make relative links from all files and symbolic links inside fromdir to destdir under the same structure of subdirectories. Subdirectories inside fromdir are recreated in destdir, not symlinked.
Optional argument extension contains the name mask: only files with names, ending in extension, will be symlinked.

linkfile fromfile destfile
Make relative link from file fromfile to destfile.

nonfail
Always return 0.
Used as handler for methods with non-null exit code which are known to be finished correctly.

rmbuild
Remove build directory of current package from WORKDIR.

patchlist
List all files in current PATCHDIR.
That can be used to get all patches, available at the moment. Method does not list content of nested directories. So patches in PATCHDIR/subdir are not printed. That can be used for conditional patches, which are added explicitly to PATCHLIST in the build by some flag.

pkgbase [packname1 ... packnameN]
Read plain package names and print base names without version to stdout, each on new line.
The rest behaviour is analogical to pkgbin, see its description.

pkgbin [packname1 ... packnameN]
Read plain package names and print names of files with their installable binary archives to stdout, each on new line.
Method reads input data from stdin and then from arguments. For stdin multiline input is read. In absence of any outer input data, it prints packages related to current P package. The format of installable archives depends on used module with package format.

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 uses inner version in binary archive name, the method output depends on the inner version of a package available.
Method takes into account KEYWORDS checking: if package is masked for current configuration, it will not produce binary packages.

pkgname [packname1 ... packnameN]
Read plain 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 of arg from D to ROOT. Directories are handled the same way as described for linkdir method, ordinary files as in linkfile.

skip message
Print the message to the stderr and exit from entire current process with code 2.
Used as method to exit with SKIP status, which is done by status_check(3).

skiplater message
Print the message to the stderr and set skip status for later check with method status_check(3).
Used as method for delayed exit with SKIP status when some part of code should be done before the exit.

tobuild
Change current directory to S, if it exists.

unlinkcopy linkfile
If given linkfile is a symbolic link from D to ROOT, delete it from ROOT and replace with real copy of former destination file from D. Method prints the new file to stdout.
Method reads arguments from stdin, single name on a line.

use flag
Return 0, if given flag is used in current launch and presents in USE. Return 1 otherwise. Method does not print any output.

use_enable flag text
If given flag is used in current launch and 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 not used in current launch and is absent in USE, print the text to stdout.
Second argument text is recommended to put into quotes.

See also

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