When the compiler is invoked it prints a herald identifying itself and prompts for input. Table 2–1 lists valid responses to this prompt (the list is displayed when ? is typed). When compilation is complete, the compiler prompts for the next file to be compiled. To exit the compiler, type <eol> to this prompt.

sourceFile is the name of a file that contains the source code that is to start the compilation. If sourceFile cannot be opened, the compiler prints an error message and returns to the “compile (? for help):” prompt. The comma after sourceFile tells the compiler to enter subcommand mode. Subcommands provide a means of specifying compiler options; they are described in Chapter 4.

moduleName and intmodFile are used when a MODULE is incrementally recompiled, as described in Chapter 3.

Responding to the compiler prompt with just =<eol> or =,<eol> tells the compiler to use the same sourceFile, moduleName, or intmodFile as it did for the previous compilation. This avoids typing the same file name in the event that it has been modified and is to be compiled again. Nonsticky subcommands are remembered from the previous compilation, and need not be specified again; sticky subcommands remain in effect, as usual (see Chapter 4 for a discussion of “sticky” and “nonsticky” subcommands).

By default, the objmod and intmod are put into files with names derived from the name of the compiled MODULE and an abbreviation for the target operating system. The abbreviation used is sometimes the standard MAINSAIL operating system abbreviation, and sometimes just the first 3 characters of the standard abbreviation; consult the system-specific MAINSAIL documentation for details. Call the operating system abbreviation used in output file names the file abbreviation.

If the compiled MODULE is FOO and the of the file abbreviation is xxx, then the compiler uses xxx-obj:foo and xxx-int:foo for the names of the objmod and intmod, respectively. For example, on SPARC UNIX, where the file abbreviation is usp, the file names for FOO are usp-obj:foo and usp-int:foo. Searchpaths are expected to have been set up to map these names into actual file names. A typical searchpath supplied by XIDAK maps xxx-int:foo into foo-xxx.int and xxx-obj:foo into foo-xxx.obj; if the mapping differs on a particular system, it is described in the appropriate operating-system-dependent MAINSAIL documentation. The default searchpaths allow the same MODULE to be compiled for different targets without the output files getting mixed up. If you always compile for the same target, you might consider changing the searchpaths so that the default file names are shorter, e.g., foo.int and foo.obj. Searchpaths are described in Section 14.2 of the MAINSAIL Language Manual and Section 21.2.35 of the MAINSAIL Utilities User's Guide.

Subcommand mode can be entered without specifying a file or MODULE by typing just a comma followed by <eol>. In this case the specified options apply to the next compilation even if they are nonsticky. This is useful in scripts that want to specify compiler options independently of which MODULE is compiled next.

The following example shows how to compile a MODULE FOO in the file foo.msl:

MAINSAIL (R) Version 16.20.<release> (? for help)
Revision: <date>
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.
*compil<eol>

MAINSAIL (R) Compiler
Copyright (c) 1984-1998 by XIDAK, Inc., Point Arena,
 California, USA.

compile (? for help): foo.msl<eol>
Opening intmod for $SYS...

foo 1
Objmod for FOO stored on foo-uir.obj
Intmod for FOO not stored

compile (? for help): <eol>

The example assumes the host system is RISC System/6000 UNIX, which has the system name abbreviation UIRS and the file abbreviation uir.

The intmod for FOO is not produced since there are no compiler options in effect that cause it to be generated. Unless the user requests otherwise, the compiler displays the names and page numbers of the source files and the names of FORWARD PROCEDUREs compiled from source libraries as they are compiled.

When the compiler finds an error in the source text, it issues an error message by calling the system PROCEDURE errMsg (unless the NORESPONSE option is in effect). The following responses to the Error response: prompt are often appropriate:

• QUIT: exit MAINSAIL.

• MAINSAIL: Abort program: exit the compiler. Any unique abbreviation will do (a p is usually sufficient).

• MAINSAIL compiler: Abort compilation: abort only the current compilation (a c is usually sufficient). The compiler prompts for the next file to compile.

• <eol>: continue compiling the same MODULE. Although valid output is not generated if a compiler error occurs, it is often convenient to see the remaining errors in the MODULE so that they can all be corrected before recompilation is attempted.

• MAINSAIL compiler: Recompile procedure (which can usually be abbreviated to r p): back up to the start of the current PROCEDURE and start over again. The compiler closes the source file and issues a message telling the user to repair the PROCEDURE. When it gets an <eol> response, the compiler reopens the source file, positions to where it remembered the start of the PROCEDURE to be, and makes sure the PROCEDURE is really still there; if so, it resumes compilation at the start of the PROCEDURE. The effect is undefined if changes were made in the MODULE's source text before the start of the affected PROCEDURE. In order to repair the source text for which the compiler is waiting, the user must either invoke (or already be running) MAINEDIT, in which case it is a simple matter to edit any files and save them before continuing the compilation, or must invoke some other text editor to do the repair before returning to the MAINSAIL compiler session.

• MAINSAIL compiler: Delayed recompile procedure (which can usually be abbreviated to d r p): same as above, except the compiler continues until the end of the current PROCEDURE, at which point it goes into the dialogue and then backs up as described above. This is appropriate when you want to find all errors in the current PROCEDURE before backing up. However, sometimes the error is such that it is better to back up immediately rather than deal with all subsequent error messages, which may in fact be due to the first error (e.g., an undeclared local variable).

Using the recompile procedure responses makes it possible to produce an objmod in a single compilation, even when errors are present in the source file at the start of the compilation, unless a change must be made at a point before the current PROCEDURE.

No intmod or objmod is generated if the compiler detects any errors in the first pass that are not repaired as described above. If the compiler detects errors during the code generation phase, the intmod and objmod are not produced.