While T2 allows to build generic GNU/Linux distributions and single packages, the most interesting thing is permanently storing what and how to build it in so called targets.

A target, its definitions, code and patches lives in a subdirectory named target/$targetname/. The clean separation from the remaining build system allows creating dedicated backups, storing the target files in some version control system and to share it with co-workers or the public.

In T2 a target can control everything, starting with the package selection, package configuration, individual custom per-package patches, overlaying the build with predefined files at the end of the build as well as how the final image should be composited together. The overlaid files usually include custom applications and setup scripts.

But when we write a target can control everything we really mean it: As one of the very first code that is run when ./t2 build-target is executed is target/$targetname/build.sh the target could in (in theory) do something entirely on its own and just loosely re-use some T2 functionality.

To start your own target you need at least a build.sh, though usually a config.in and pkgsel will control the basic settings.