All Starlink software uses the SYSTEM environment variable
to control machine dependent aspects of software construction. It
is normal for accounts doing software development to set this up
in their .cshrc file. The values currently in use
are,
All Starlink software uses the UNIX system utility make to build
its software. The associated make files are written in a generic fashion
with the aim of containing no system dependent statements. Operations
which are potentially non-portable (eg. the command to replace an object
module in an archive) are tokenised. Each Starlink package then has a
Bourne shell script called mk which sets up the values of these
tokens depending on the value of $SYSTEM. All make files are
therefore invoked using this mk script rather than running
make directly.
Make files define a number of targets. The ones used by Starlink
are usually high level operations such as `build the system from the
source code', or `install this package into the Starlink tree'. These
high level targets are called primary targets. The secondary
targets are the actual files which are built or modified by the system.
Generally it is good practise not to access the secondary targets directly.
A make target is activated if the file which the target specifies
is to be built is out of date with respect to its dependencies. A target
with no dependencies is always activated.
For primary targets it is not unusual to have dummy or zero length
files which due to their date stamp in the file system can be used
as date carrying flags. Starlink software usually maintains 3 such files
in each directory called .BUILT, .INSTALLED and .TESTED.
These flag files tell the system in which of 4 potential states the package
exists. In ASTERIX, because we build our volatile files from one copy of
the source code, these files are suffixed with the value of $SYSTEM.
Starlink aren't too keen on this, but who cares, and they get flack for
having multiple copies of software.