Moving Dependency Tracking Into The CM Process

CM tool needs to support the concepts of "affected by" and "affects". It is also useful if it supports the concepts of "used by" and "uses". In addition, if the CM tool can track the "Make" or "compile" rule for each file class and the special purpose Compile options for any CI which has special compile options, it is able to generate compile scripts. Generally, if a CM tool can dynamically generate a Make file, it already has the information it requires to support these concepts and capabilities. If it has a good query capability, the return could be all the greater.

A good CM tool can even generate Make and Build files and scripts which eliminate the need to create intermediate library archives, which are often created so that the link tools can help you to implement promotion levels with incremental compiles. Instead of requiring a full object code directory for each promotion level (checked-in, built, integrated, tested, production, and perhaps team group levels as well), only object code files which change from level to level should need re-compiling and storing at each level, using the next higher level as part of the search order in the linking process. Again, with smaller projects this isn't an issue. But give me a large development project with many variants or customizations across several different target platforms, and the savings add up: compile time, storage, backups, network distribution throughout the design environment, etc.

Summing Up

It may not change the world, but moving dependency tracking into the CM system

• Allows layering support to increase software re-use
• Eliminates date-based dependency actions
• Moves the process out of the Make or Build File into the CM Tool Process
• Provides dependency query from any dynamic (or static) view
• Provides a level of interface (i.e. header) change impact analysis
• Helps support promotion-level based object directories.