whouses - impact analysis in a clearmake build environment
You give me a clean CR, I'll give you a clean impact analysis.
Run this script with the -help option for usage details. Here are
some additional sample usages with explanations:
whouses foobar.h
Shows all DO's that make use of any file matching /foobar.h/.
whouses -recurse foobar.h
Same as above but follows the chain of derived files recursively.
whouses -exact /vobs_xyz/include/foobar.h
Shows all DO's that make use of the specified file (must be given as a an absolute pathname).
Whouses provides a limited form of ``impact analysis'' in a clearmake build environment. This is different from traditional impact analysis (see CLASSIC CODE ANALYSIS COMPARED below for details) and in particular operates at the granularity of files rather than language elements.
Whouses is best described by example. Imagine you have a VOB '/vobs_sw' in which you build the incredibly simple application foo from foo.c. You have a Makefile which compiles foo.c to foo.o and then links it to produce foo. And let's further assume you've just done a build using clearmake.
Now, foo is a DO which has a config record (``CR'') showing how it was made. Whouses analyzes that CR and prints the data in easy-to-read indented format. For instance:
% whouses -cr foo foo.c
/vobs_sw/src/foo.c =>
/vobs_sw/src/foo.o
The ``-cr foo'' points to the derived object from which to extract and analyze the CR; it will be implicit in the remaining examples. The output indicates that foo.o uses foo.c, or in other words that foo.c is a contributor to foo.o. If we add the -recurse flag:
% whouses -r foo.c
/vobs_sw/src/foo.c =>
/vobs_sw/src/foo.o
/vobs_sw/src/foo
We see all files to which foo.c contributes, indented according to how many generations removed they are. If we now add -terminals
% whouses -r -t foo.c
/vobs_sw/src/foo.c =>
/vobs_sw/src/foo
Intermediate targets such as foo.o are suppressed so we see only the ``final'' targets descended from foo.c.
We can also go in the other direction using -backwards:
% whouses -b -e foo
/vobs_sw/src/foo <=
/vobs_sw/src/foo.o
Which shows foo.o as a progenitor of foo. Note that the arrow (<=) is turned around to indicate -backwards mode. We also introduced the -exact flag here. By default arguments to whouses are treated as patterns, not file names, and since foo has no extension it would have matched foo.c and foo.o as well. We can combine recursion with backwards mode:
% whouses -b -e -r foo
/vobs_sw/src/foo <=
/vobs_sw/src/foo.o
/vobs_sw/src/foo.c
/vobs_sw/src/foo.h
/vobs_sw/src/bar.h
And discover that foo.h and bar.h were also used.
When used recursively in the forward direction, this script answers the question ``if I change file X, which derived files will need to be rebuilt''? This is the classic use, the one for which it was written.
Because extracting a recursive CR can be quite slow, whouses provides ways of dumping the CR data to a file representation for speed. Use of -save:
% whouses -cr foo -save ...
will write out the data to foo.crdb. Subsequently, if foo.crdb exists and is newer than foo data will be taken from it rather than re-generating the recursive catcr report. See also the -db and -fmt flags.
The default save format is that of Data::Dumper. It was chosen because it results in a nicely indented, human-readable text format file. Provision is made for subclassing to alternate storage formats, and subclasses for Storable and Data::Denter are provided as examples. Although the Storable format may be somewhat faster than the default, the real reason for the override capability is to allow an actual, fast database to be used.
Derived objects matching the Perl RE /\.AUDIT/i are ignored. These are presumed to be ``meta-DO's'' by convention, which aren't part of the build per se but rather pseudo-targets whose only purpose is to hold CR's which refer back to all real deliverables.
Whouses can best be described by comparison with ``real'' impact analysis products. There are a number of full-scale tools on the market. Typically, these work by parsing the source code into some representation which they can then analyze. It's a powerful technique but entails some tradeoffs:
The minuses above are not design flaws but inherent tradeoffs. For true code impact analysis you must buy one of these tools and accept the costs.
Whouses doesn't attempt code analysis per se. As noted above, true code analysis programs are tied to language but not to an SCM system. Whouses flips this around; it doesn't care about language but it only works with build systems that use clearmake, which is part of ClearCase.
David Boyce <dsb@boyski.com>
Copyright (c) 2000-2001 David Boyce. All rights reserved. This Perl program is free software; you may redistribute and/or modify it under the same terms as Perl itself.
This is currently ALPHA code and thus I reserve the right to change the UI incompatibly. At some point I'll bump the version suitably and remove this warning, which will constitute an (almost) ironclad promise to leave the interface alone.
I've tried to write this in a platform independent style but it has not been heavily tested on Windows (actually it hasn't been all that heavily tested anywhere). It does pass ``make test'' on Windows and appears to work fine in limited testing.
perl(1), ClearCase::CRDB(3)