Similar to make and other CASE tools based on dependence checking, VMake uses a ``depth first'' algorithm[Fel79, Hei89]. VMake stores the source file meta data in a tree which is identical to the project directory tree. Each source file is an object node in the tree. Include files, object files, libraries and executables are added in their respective position into an acyclic dependence graph. In contrast to make, VMake treats include files and all other implicitly managed files the same way as the files appearing explicitly in VMake rules. To check a goal, VMake takes the list of all subgoals on which the current goal depends and recursively evaluates each subgoal from left to right. If a goal has already been checked, VMake immediately checks the next goal. While checking the dependences VMake executes any goal in background (automatic code generation, language binding, compilation, etc.) using the queuing sub-agent and possibly parallelizes the build process over a workstation cluster (using remote shells under UNIX and the batch queuing system under VMS). The maximum number of jobs/workstation can be specified (see Section 8.5). Due to the concept of queuing files for update actions in the first stage and then later really build them, files may be built in a different order than the standard ``depth first'' algorithm. This behavior is achieved with the queuing sub-agent of VMake and not implied by the dependence check.
The dependence information for include files of a project is stored in the project save file. The time stamp of the last dependence scan is compared to the current modification time and if the information is out-of-date it is automatically regenerated. This check is done for each source and include file and is a lot faster because single files are parsed for includes and global defines usage instead of recursively going through all included files each time. Using standard CASE tools the action of recreating dependence information must be activated by the developer and is unconditional done for all source files. So many include files may be parsed multiple times. In contrast to this Jam recreates all dependence information on each evocation because no saved information is available.