The automated build of a package, as implemented in the T2 SDE, can be separated in several phases which have a associated hook where package configuration or targets can hook custom modifications in.
The hooks are:
prepare: Preparation of the package build. The hook 'prepare' is evaluated as one of the first actions when a package build is started.
prepatch: One of the first things the build system does, is the extraction and patching of the package archive files. Before applying the patches the hook 'prepatch' is evaluated.
postpatch: The hook 'postpatch' is evaluated after applying the patches.
postdoc: The build system features an automatic copy operation of most useful documentation files, like the packages README, LICENSE, AUTHORS, and so on. The hook 'postdoc' is evaluated after this operation.
preconf: Most packages need a configuration process - for example running the GNU/autoconf script. Before running the detected configure with auto-detected options the hook 'preconf' is evaluated.
premake: Before running make the hook 'premake' is evaluated.
inmake: Between running 'make' and 'make install' the hook 'inmake' is valuated.
postmake: After running 'make install' the hook 'postmake' is evaluated.
postinstall: After the whole normal build process and before the final file list creation the hook 'postinstall' is evaluated.
postflist: After the file list creation for the package the hook 'postflist' is evaluated.
As at this point the package file list (flist) is already created, you need to manually append files to the flist in the case new files are created in the postflist hook with 'add_flist':
add_flist /some/new/file
finish: As last step in the package build - after all the /var/adm/* meta-data creation - the hook 'finish' is evaluated.
This is usually used to do run some management code, for example the ccache support prints some pretty statistics at this time.
At this point it is not possible to modify package files anymore as all /var/adm/* meta-data is finalized!
Usually you just want to add an operation to a hook - this is done with:
hook_add hook-name priority command
The priority (which can be in the rang of 0-9) is used to sort the attached operations to run them in a predictable order.
For example if you want to copy a directory named 'tools' to the documentation directory of the package because it contains some useful example tools, you just need to add:
hook_add postmake 5 "cp -vrf tools $docdir"
to the package's .conf file. If you have a more complex operation to be done inside a hook you should define a function and just attach the new function to the hook:
mypackage_pm () {
# some code
}
hook_add postmake 5 "mypackage_pm"
In the rare case where you package a unusual and complex package which completely disables the whole automatic build system you might get into a situation where you want to evaluate the content of a hook to let targets apply custom modifications on the package.
Evaluation of a hook is done with:
hook_eval hook-name
this will run all operations attached to the hook sorted by the supplied priorities.
You most likely will never need to get in touch with this, since as the time of writing only the gcc, glibc and kiss package make use of custom hook evaluation ...