The process of adding a package to the build system, and autoconfing it, is reasonably mechanical. The main differences from the traditional build system are as follows.
There is now no ./mk file, and so no platform
configuration using the $SYSTEM environment
variable. Instead, all platform dependencies should be
discovered by the configuration process. It is only in
rather extreme cases that you will need to resort to
platform-specific code, and that should be handled by
the starconf macro STAR_PLATFORM_SOURCES.
You should try to avoid mentioning or referring to any specific platform when configuring. Test for features, working with those you find, and working around those you don't; don't test for platforms and believe you can reliably then deduce what features are available.
Traditional Starlink makefiles had two phases, `build' and
`install' (plus the various export targets). These makefiles
often did on-the-fly editing of scripts as they were being
installed, to edit in version numbers, or the correct path to
Perl, for example. There was also implicit configuration done
in the ./mk script, which specified
platform-specific compiler flags, or versions of `tar'.
GNU-style projects, on the other hand, have three phases,
`configure', `build' and `install', and source file editing
happens only in the first two -- installation consists only of
the installation of static files. Most configuration editing
happens at configure time, when .in files are
substituted with static information, such as the absolute paths
to programs, determined as part of configuration. In the case
where the substitution involves installation directory
variables, GNU (and thus general) conventions demand that this
be done at build time, since these directories involve the
$(prefix) makefile variable, and it is deemed
legitimate for the user to specify a different value at build
time (make prefix=xxx) from that specified or implied
at configuration time. The user may then specify a different
prefix again at install time (make prefix=yyy
install) for the purposes of relocating or staging the
install, but this must not invalidate the value of
$(prefix) which may have been compiled into
applications. This is discussed in some detail in section
4.7.2 Installation
Directory Variables of the autoconf manual, but you
generally do not have to worry about it, since it is rather rare
in practice that you have to compile installation directories
into the applications and libraries that you build.
In general, whereas traditional Starlink makefiles quite often performed spectacular gymnastics at install time, GNU-style makefiles generally do nothing at install time, other than occasionally adding extra material to the install via one of the installation hooks supplied by automake (see section What gets installed of the automake manual).
In the traditional build system, the master source was regarded as rather private to the developer who `owned' the code, who was free to use whatever occult means they desired to produce the sources which were put into the three distribution objects, `export_source' (just the source), `export_run' (just the executable) and `export' (both). Now, everything should be put into the CVS repository, including any code-generation tools either as separate packages or as local scripts, and it is this source set which is used for nightly builds and the like. If you need tools to generate some of the distributed sources, and they cannot be included in the package for some reason, they should be checked in, and your component should declare a `sourceset' dependency on the required tool (see Appendix A.16).
With these remarks out of the way, the following is a description of the steps involved in bringing first an application into the new fold, and then a third-party component.