One exceptional key feature of T2 is the Text/Plain and tag based description format outlined in the last section in combination with the automated build system.
The build systems extracts the tarballs and analysis the file structure to decide how to build the package.
A quick overview about the intention of the various build stages:
Stage 0:
In the initial stage a fresh cross-compile toolchain is bootstrapped. This includes a OS header package like linux-header defining the kernel ABI[5], the C-library header like glibc defining the user-space ABI, as well as the cross-assembler and linker from binutils and cross C/C++ cross-compiler, usually gcc. Also some tools like tar and cpio are built to have known good versions.
This cross-compile setup is always used, even on native build. Not so much for regression testing, but because the resulting system differs in ABI due to major glibc, gcc updates.
Stage 1-2:
In stage one and two the selected packages are cross-compiled. On native builds just a minimal set of packages for a freestanding system is cross-compiled.
Stage 3-4:
After the cross stages the system changes -via chroot- into the fresh stage 1 environment and bootstrap (re-compiles) the native tools, to make sure they have not build invariance and work reliable. This is often also referred to as self-hosting: being able to rebuild itself.
Stage 3-4 are mostly unused and only exist because the stages where spread over the range a single digit can hold.
Stage 5-8:
Normal build stages, all the selected packages are built.
Likewise, stage 6-8 are mostly unused and only exist because the stages where spread over the range a single digit can hold. Some packages are rebuilt to solve dependency graph cycles due optional features of packages.
Stage 9:
In the final stage 9 everything is compiled again to test everything actually still works. Also the automated regression tested creating the .cache files uses this rebuild phase to guarantee all optional dependencies are recorded in the .cache files.
This rebuild stage is disabled by default and only paranoid people with excessive computing power need to enable it.
The packages that have to be built in every stage are defined in config/$cfg/packages. ./t2 build-target invokes ./t2 build for every package chroot'd in the build/ directory.
The build priority of a package controls at which time during the whole target build a package is build. The priority does not need to be unique, so it does not matter if another package has the same build priority. In the case of duplicate priorities the packages with the same priority are built in their alphabetical order.
But the initial priority of a new package is only a first sorting, and will be puzzled after an reference build regularly to solve all optional dependencies. This dependency information is used to spread the packages over the nodes for a cluster build (the linear priority is not used at all in this case) and e.g. for the end user T2 Linux installer.
It is planned that future versions of T2 will not require this scheduling hint and instead order the packages by the dependency graph as obtained by the .cache files.
GNU/Autoconf: ./configure ; make ; make install (including a autogen.sh or libtoolize, aclocal, automake, autoconf run to generate the actual configure et al.)
X11 Imakefile: xmkmf ; make ; make install
traditional Makefiles: make ; make install
Python setup.py: python setup.py build install
Perl Makefile.PL: perl Makefile.PL
cmake: cmake ; make ; make install
Only if the automated procedure is not sufficient for a package to be built, additional 'glue' code is necessary in the package's '.conf' file.