Eliminating the Cost

There may be times when this cost is unacceptable. For example:-

• When needing to minimise the virtual size so as to reduce swap space.

• When going through a rapid development cycle and requiring the fastest possible link time.

• When an SU is non-standard, for example Electronics Calibration, and is unwanted from any application to be built locally.

Then you may prefer to give up the ability to select SUs at execution time in favour of removing unwanted SUs entirely from the program. Two separate mechanisms are provided to eliminated unwanted SUs, they are provided to serve different needs:-

DISCONNECTED SU

All calls to SUs made by the Software Unit Control (remember, it is these calls that force everything to be loaded), go via the code sequence:-

su_call.inc

Disconnecting an SU means removing all calls to it from this code sequence. Consequently, the SNOlib library is changed and that all applications built with it cannot use the SU until it is reconnected. SU disconnection is best suited to cases where the SU is of no possible interest to the users at the local site.

DUMMY SU

This involves no change to SNOlib. Instead the user provides, for each unwanted SU, a set of dummy routines for all calls to it in su_call.inc and hence effectively blank it off. This method can be changed from application to application, allowing each to be fine-tuned as required.

So, during installation, the local software librarian decides what, if any, SUs are to be disconnected and then builds SNOlib. Individual users can then, if needs be, use dummy SUs to complete the job.