next up previous contents
Next: 8.3.1 States of Files Up: 8 Algorithm of VMake Previous: 8.2 Resolving Symbolic Names

8.3 VMake Class System

  Due to the object oriented approach VMake each file is represented by an unique typed object. The class hierarchy of file objects has two different base classes which are

vm::File
describes source files, objects, libraries and programs in working projects.
vm::ExternalFile
describes files which are external resources, e.g., declared in the project description file, or files from an installation.

Both of these two classes store the following information about the file:
  1. the file name with full path information,
  2. the last modification time
  3. the file state,
  4. the associated directory object and project object (back references).
All other files types are subclassed from these two classes. To store the information of the source tree of a working project VMake needs the additional VLisp vm::Directory for storing directory information. In these directory objects references to all files in the corresponding directory are stored. Each target object (used as goal) has direct references to its source objects. Using this technique no file searches are needed for checking dependences.

All classes associated to different file types in a working project are derived from the basic vm::File. The full class hierarchy is shown in Table 8.1.

  table4459
Tabelle 8.1: Class hierarchy for working files

The method checkfile for dependence checking is implemented directly in the base class. It checks whether the file need to be updated or not. Subclassed classes may override this method due to additional information.

User defined extension rules may be derived from any of these classes or use any of them. As an example, the project for BISON implements the Bison-Target by subclassing the vm::BisonFile from the built-in vm::YaccFile (see Appendix D). The classes vm::CObjectFile and vm::C++ObjectFile are used to compile the automatically generated parser code into an object file which is then bound to the symbolic name.

External files are handled similar to normal files. The only difference is, that they have to exist and no update action is possible. Their class hierarchy is shown in Table 8.2.

  table4551
Tabelle 8.2: Class hierarchy for external/installed files

The vm::ExternalInclude stores all dependence information of included files and used system defines for later checking. Both, programs and shell scripts are handled by the vm::ExternalProgram. The vm::ExternalTacDefinition is necessary because the TAC definition may be used in a different project.




next up previous contents
Next: 8.3.1 States of Files Up: 8 Algorithm of VMake Previous: 8.2 Resolving Symbolic Names

IUE WWW server
Fri Jan 3 17:00:13 MET 1997