Running the CML2 tools

The CML2 implementation consists of two Python programs: cmlcompile and cmlconfigure. The compiler, cmlcompile, generates a pickled representation of a rulebase from one or more files of CML2 rules. The interpreter, cmlconfigure, reads in a rulebase and uses it to inform a configuration dialogue with the user.

The separation between front and back ends serves two purposes. One: Front ends don't need to know about and are not affected by the details of the compiler implementation. Two: The CML2 rulebase doesn't have to be recompiled every time a front end is run.

The end result is a pair of configuration files, the defconfig and the macrofile. These are in formats inherited from CML1 (see the section called CML2 configuration file formats for complete specification). The defconfig consists of a set of variable definitions in shell syntax; it can be re-read by a future instance of cmlconfigure to set defaults. The macrofile is a list of C-style #define macros intended to be included in kernel C code.

The compiler, cmlcompiler, requires one or more CML2 rules files as arguments. It has two options:

-o filename

Set the file to which the compiled rulebase is written. By default, if no -o option is given, the rulebase goes to rules.out.

-d

Enable debugging output to stdout.

The interpreter, cmlconfigure, takes at most one filename argument: the rulebase to be interpreted. If no argument is specified, it reads from rules.out. The interpreter recognizes the following options:

-h outfile

Set the location to which cmlconfigure should write its file of C macros. There is no default; if there is no -h, option no macro file is written.

-iconfigfile

Read in a configuration. The file is expected to be in the same defconfig format written by cmlconfigure. Values (including n) are set as though selected interactively by the user.

-Iconfigfile

Read in a configuration. The file is expected to be in the same defconfig format written by cmlconfigure. Values (including n) are frozen and will be displayed but not modifiable during the configure run.

-l

List. Run in batch mode to generate a menu map (that is, a tree diagram of all the menus and question symbols in the system.)

-s outfile

Set the location to which cmlconfigure should write its defconfig file of shell variable settings. Explicit n values are saved. This file will be loadable by cmlconfigure. There is no default; if there is no -s option no defconfig file is written.

-t

Force tty (line-oriented) mode.

-c

Force curses (screen-oriented) mode.

-x

Force X (GUI using Tk) mode.

-d

Increment the debug flag.

-D

Preset a symbol. -DFOO sets FOO=y at startup. -DFOO=xxx may be used to specify a value. The value of a preset symbol is frozen; that is, it will never be queried.

-S

Don't hide elided symbols. When this option is on, suppressions are ignored. Only symbols that have derived a frozen value from -D or constraints are skipped. This may be useful if you know that you want to set configuration symbols deep in the hierarchy and have their requirements propagate upwards, as opposed to the normal sequence in which you refine your way down from the top of the tree with symbols becoming visible only when they are unmasked by previous questions.

-V

Print the configurator version and exit.

The environment variable CML2OPTIONS may specify command-line switches (but not arguments). Switches taken from CML2OPTIONS are processed after any compiled in by an "options" directive in the rulebase, but before switches specified on the actual command line.

The environment variable BROWSER may specify a colon-separated list of browser commands, to be used in making URLs in the help widgets live. Each command should have the string "%s" in it where the URL can be substituted. The CML2 front end will try the commands in succession until one succeeds. The default sequence is mozilla, then any netscape already running, then a new netscape instance, then lynx, then w3m.