FDL and make Comparison
The utility make manages flow and dependency information in software projects as well as in many other domains. It is portable across multiple platforms, it is free, it is a standard, and everybody familiar with it knows its idiosyncrasies.
In the development of FlowTracer, we wanted to make sure that all the makefiles could still be used to build the design trace. For example, we wanted it to be possible to transfer the flow information from the makefile into the design trace using either vovmake or using the "interception" technique.
After many years of FlowTracer development, it has become increasingly hard to justify the effort of maintaining a makefile, with its arcane syntax consisting of %.c, $<, $@ and invisible tabs, only to get a representation of dependencies that is, in many cases, incomplete, incorrect, or both.
- All dependencies are maintained up to date automatically.
- Dependency constraints are never violated.
- In a heterogeneous network, one can build targets for any architecture
easily. For example, to build a MacOS-X binary from any window with access
to the FlowTracer server, we can enter:
% vsr ../macosx/bin/vovserver - It is easy to define sets of targets for the user's convenience. For
example, in the development of FlowTracer there is a set
called All:include consisting of all of the generated headers used during
compilation. To retrace all the files in this set, use:
% vsr -set All:include - The build-rules are expressed with a Tcl script. The Tcl syntax is simpler than that of a traditional makefile and allows proper looping and conditional constructs. With Tcl, rules can be expressed more compactly than with make.
- Designers have complete control on the working directory and on the execution environment.
- FlowTracer offers coordination of team effort. Multiple overlapping build requests, coming possibly from different designers, will never cause any tool to be executed more than once.
- Changes to the build rules themselves can also be traced.
- FlowTracer supports parallel development of multiple variants. For example, for each piece of software one typically needs a debuggable version (-g), an optimized version (-O), and a profilable version (-pg).
- FlowTracer supports parallel development on multiple platforms.
- FlowTracer supports Runtime Change Propagation Control. It understands that some changes do not need to be propagated. With proper barriers to change propagation, FlowTracer frees the designers from the tyranny of timestamps.
- In lines of code, the flow written with FDL are much smaller than the corresponding Makefiles, resulting in lower development and maintenance costs.