Most of the time I work in scripting languages, ie: TCL/TK, etc. One can use grep to extract all "package require" statements from the source to construct a file dependency tree.
Likewise, one can recursively follow function calls (internal or external) to determine procedure dependencies. At least for DLL in the MS world, most should be delivered with a text file that is navigable via the "API Viewer" ... hence again if this is available it would be relatively easy. However, obviously in library declarations within your own source, this should be navigable to the degree that available source references it's own dependencies. Presumably DLL/SO libraries would have some documentation that yielded information on it's dependencies and that would be out-of-scope for the dependency browser. So, really, it would be based on your own project source code navigation, ending at the binaries. In our case, we've defined what we call a PICSL model for software development (layered per Presentation, Interface, Component, Services/frameworks (for the component), Library(point of interface to oodb)). It looks like sort of a micro version of SOA within the program structure itself. At any rate, just thought it would be interesting. Frankly you could have a combined browser that would show the function/method dependencies both intra-module and inter-module as long as it was from source. Thanks again -- <http://forum.pspad.com/read.php?2,28693,28708> PSPad freeware editor http://www.pspad.com
