view release on metacpan or  search on metacpan

WHOUSES.html  view on Meta::CPAN

        % whouses -do foo -save ...</pre>
<p>will write out the data to <em>foo.crdb</em>. Subsequently, if <em>foo.crdb</em>
exists it will be used unless a new the <code>-do</code> flag is used.  See also
the <code>-db</code> and <code>-fmt</code> flags.</p>
<p>The default save format is that of <strong>Data::Dumper</strong>. It was chosen
because it results in a nicely indented, human-readable text format
file.</p>
<p>
</p>
<hr />
<h1><a name="selecting_derived_objects_to_analyze">SELECTING DERIVED OBJECTS TO ANALYZE</a></h1>
<p>If a <code>-do</code> flag is given, the CRs are taken from the specified derived
object(s).  Multiple DOs may be specified with multiple <code>-do</code> flags
or as a comma-separated list. Alternatively, if the <code>CRDB_DO</code>
environment variable exists, its value is used as if specified with
<code>-do</code>.</p>
<p>If no DOs are specified directly, <code>whouses</code> will look for stored DO
data in files specified with <code>-db</code> or the <code>CRDB_DB</code> EV. The format is
the same as above.</p>
<p>Failing that, <code>whouses</code> will search for files named <code>*.crdb</code> along a
path specified with <code>-dir</code> or <code>CRDB_PATH</code>, defaulting to the current
directory.</p>
<p>
</p>
<hr />
<h1><a name=".audit_files">.AUDIT FILES</a></h1>
<p>As a special case, derived objects matching the Perl regular expression
<code>/\.AUDIT/i</code> are ignored while traversing the recursive config spec.
These are presumed to be <em>meta-DOs</em> by convention, which aren't part
of the production build per se but rather pseudo-targets whose only
purpose is to hold CRs referring back to all real deliverables. Thus
if you construct your Makefile to create a meta-DO, you might want to
name it <code>.AUDIT</code> or <code>.prog.AUDIT</code> or something.</p>
<p>
</p>
<hr />
<h1><a name="clearcase::crdb">ClearCase::CRDB</a></h1>
<p>Most of the logic is actually in the <code>ClearCase::CRDB</code> module; the
<code>whouses</code> program is just a wrapper which uses the module. It's done
this way so ClearCase::CRDB can provide an API for other potential
tools which need to do CR analysis.</p>
<p>
</p>
<hr />
<h1><a name="true_code_analysis_compared">TRUE CODE ANALYSIS COMPARED</a></h1>
<p>Whouses is somewhat different from ``real'' impact analysis products.
There are a number of such tools on the market, for example SNiFF+ from
WindRiver.  Typically these work by parsing the source code into some
database representation which they can then analyze. It's a powerful
technique but entails some tradeoffs:</p>
<p>
</p>
<h2><a name="minuses">MINUSES</a></h2>
<ul>
<li></li>
A true code analysis tool must have knowledge of each programming
language in use. I.e. to add support for Java, a Java parser must be
added.
<p></p>
<li></li>
A corollary of the above is that it requires lot of work by expert
programmers. Thus the tools tend to be large, complex and expensive.
Note: there is also <em>cscope</em> which is free, and maybe others. But as
the name implies <em>cscope</em> is limited to C-like languages.
<p></p>
<li></li>
Another corollary is that the tool must track each advance
in each language, usually with significant lag time, and
may not be bug-for-bug compatible with the compiler.
<p></p>
<li></li>
Also, since analysis basically entails compiling the code, analysis of
a large code base can take a long time, potentially as long or longer
than actually building it.
<p></p>
<li></li>
If some part of the application is written in a language the tool
doesn't know (say Python or Visual Basic or Perl or an IDL), no
analysis of that area can take place.
<p></p></ul>
<p>
</p>
<h2><a name="pluses">PLUSES</a></h2>
<ul>
<li></li>
The analysis can be as granular and as language-knowledgeable as its
developers can make it. If you change the signature of a C function, it
can tell you how many uses of that function, in what files and on what
lines, will need to change.
<p></p>
<li></li>
A code analysis tool may be tied to a set of languages but by the same
token it's NOT tied to a particular SCM or build system.
<p></p></ul>
<p>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.</p>
<p>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 within a ClearCase VOB.</p>
<p>Whouses takes the <em>config records</em> generated by clearmake, analyzes
them, and tells you which files depend on which other files according
to the CRs. Both techniques have fuzziness of different kinds: code
analysis predicts what the real compiler will do based on what the
analysis compiler found; divergence is possible. Whouses predicts what
the next build will do based on what the last build did.  If changes
have taken place since, divergence is possible here too.</p>
<p>
</p>
<hr />
<h1><a name="author">AUTHOR</a></h1>
<p>David Boyce &lt;dsbperl AT boyski.com&gt;</p>
<p>
</p>
<hr />
<h1><a name="copyright">COPYRIGHT</a></h1>
<p>Copyright (c) 2000-2006 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.</p>
<p>
</p>
<hr />
<h1><a name="status">STATUS</a></h1>
<p>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