With the Project-RuleFile (see Project-RuleFile) a rule definition file can be specified to implement new rules for a project. Currently this facility is used to add the Bison-Target for BISON[Don96] and the Flex-Target for FLEX[Pax96]. The complete examples of these rule extensions are given in Appendix D.
To implement a new rule in VMake, a rule definition LISP-file must be defined. The rule itself is defined by the VMake macro defrule as shown in Figure 4.5. A symbolicName must be the first parameter to identify the target object of the rule. All other parameters are implemented as key arguments.
Abbildung 4.5: Definition of an External Rule
The predefined macro vm::requiredpar checks whether the key parameter infile is given and prints an error message if the parameter is missing. The key parameter extend is optional and may have a default value within the rule implementation. The new rule has the name ExtensionRule and is available within the project and all parent projects. To check the existence of a value for a key, the macro vm::boundpar can be used. The user is responsible to define the rule such that all file objects are correctly entered into the internal database structures of VMake. Otherwise correct dependence checking and execution of VMake cannot be guaranteed. The return value of a rule is always the list of target objects or the target object itself.
If some symbolicNames are required for the rule evaluation, the first LISP function in the rule body must be a vm::requiredsym. This enforces that the argument symbolicNames of this macro are already known by VMake when the rule is evaluated later.
Usually new rules define sub-classes from internal VMake file classes
(see Section 8.3). Their extensions are stored as instance
variables (per object) or as shared class variables (common for all
objects). The required methods to cooperate with the VMake kernel, either
implemented explicitly or inherited from the parent class are
These methods usually call their corresponding parent method to get
the default information from the built-in class. Specific information is
then added. A good example for this behavior are the rules
Bison-Target and Flex-Target with their implementation
of the method getdepfiles (see Appendix D).