An incremental recompilation is indicated by specifying moduleName or intmodFile to the compiler prompt, followed by a comma to enter subcommand mode. One of the subcommands must be RECOMPILE, which specifies the PROCEDURE(s) to be recompiled. The compiler must be able to find the old intmod, and, if code is generated, the old objmod.

Unless otherwise specified using OUTINTFILE or OUTINTLIB, the new intmod and objmod are stored under the default file names; they do not automatically replace the old intmod and objmod.

The advantage of incremental recompilation over full compilation is speed, since only the specified PROCEDUREs are processed. The disadvantage is that the new intmod and objmod are larger than the old ones, since the code for the recompiled PROCEDUREs is added to the end of the objmod, and the information for the recompiled PROCEDUREs is added to the end of the intmod, but the space occupied by the original code and information is not reused. Since incremental recompilation is used during program development, the larger intmod and objmod should not be a major drawback. At any time a compilation of the entire MODULE can be used to produce an objmod and intmod with no unused space.

In order to be able to recompile a MODULE, it must be initially compiled with the INCREMENTAL option. This tells the compiler to put sufficient information into the intmod to allow recompilation. The RECOMPILE subcommand tells the compiler that an incremental recompilation is to be done. This subcommand takes a list of names, separated by spaces, of those PROCEDUREs that have been changed. The effects of changes to the source text of the MODULE outside the bodies of these PROCEDUREs are undefined. The compiler issues an error message if it detects a change outside of the specified PROCEDUREs, but it is not necessarily able to detect all such changes. The user must be careful to remember and include in the list all PROCEDUREs that were changed.

It is somewhat inconvenient that, in order to use incremental recompilation, the user must tell the compiler what PROCEDUREs have been changed; it would be easier if the compiler could automatically figure this out. It is also inconvenient that if any change, however slight (e.g., even to a comment), is made outside of any PROCEDURE, then incremental recompilation cannot be used. These restrictions may be relaxed in a future release.

The options specified by the following compiler subcommands are cleared if the RECOMPILE or INCREMENTAL option is set:

MODTIME MONITOR PERMOD PERPROC PERSTMT PROCTIME NOMONITOR

In other words, a MODULE cannot be compiled with the INCREMENTAL option, or recompiled, and also have a performance monitoring option in effect. This is due to the difficulty of incrementally altering the effect of these options, and this restriction may be lifted in a future release.

When recompiling, the options affected by the following compiler subcommands are set from the old intmod and the current settings are ignored for the current compilation:

ALIST DEBUG GENCODE GENINLINES INCREMENTAL SAVEON NOALIST NODEBUG
NOGENCODE NOGENINLINES NOINCREMENTAL NOSAVEON

The treatment of subcommands governing optimization, checking, and arithmetic checking is described in Chapter 16 of the MAINSAIL Language Manual.

An error is reported at the start of a compilation if the INCREMENTAL or RECOMPILE subcommand is in effect and the FLI subcommand is also in effect.

All other compiler subcommands have their normal effect during a recompilation. All sticky subcommands have their normal effects on later compilations, even if ignored on the current compilation because the INCREMENTAL or RECOMPILE subcommand is in effect.

If a PROCEDURE is recompiled, and was expanded inline in the MODULE being recompiled (either because it was declared INLINE or because it was invoked INLINE), then expansions of the PROCEDURE in non-recompiled PROCEDUREs cannot be updated. Whenever the compiler detects this situation it prompts for whether it should abort or proceed with code generation.