|
NAMEModule::Dependency::Indexer - creates the databases used by the dependency mapping moduleSYNOPSISuse Module::Dependency::Indexer; Module::Dependency::Indexer::setIndex( '/var/tmp/dependency/unified.dat' ); Module::Dependency::Indexer::makeIndex( $directory, [ $another, $andanother... ] ); Module::Dependency::Indexer::setShebangCheck( 0 ); DESCRIPTIONThis module looks at all .pm, .pl and .plx files within and below a given directory/directories (found with File::Find), reads through them and extracts some information about them. If the shebang check is turned on then it also looks at the first line of all other files, to see if they're perl programs too. We extract this information:
When it has extracted all this information it uses Storable to write the data to disk in the indexfile location. This search is quite an expensive operation, taking around 10 seconds for the site_perl directory here. However once the information has been gathered it's extremely fast to use. FUNCTIONS
NOTE ABOUT WHAT IS INDEXEDA database entry is made for each file scanned. This makes the generally good assumption that a .pl file is a script that is not use/required by anything else, and a .pm file is a package file which may be use/required by many other files. Database entries ARE NOT made just because a file is use/required - hence the database will not contain an entry for 'strict' or 'File::Find' (for example) unless you explicitly index your perl's lib/ folder.E.g., if 'Local::Foo.pm' uses strict and File::Find and we index it, its entry in the database will show that it depends on strict and File::Find, as you'd expect. It's just that we won't create an entry for 'strict' on that basis alone. In practice this behaviour is what you want - you want to see how the mass of perl in your cgi-bin and site_perl folders fits together (for example), or maybe just a single project in CVS. You may of course include your perl lib directory in the database should you want to see the dependencies involving the standard modules, but generally that's not relevant. USE OF THE DATANow you've got a datafile which links all the scripts and modules in a set of directories. Use ...::Info to get at the data. Note that the data is stored using Storable's nstore method which _should_ make these indexes portable across platforms. Not tested though.ADVICE, GETTING AT DATAAs Storable is so fast, you may want to make one big index of all folders where perl things are. Then you can load this datafile back up, extract the entry for, say, Local::Foo and examine its dependencies (and reverse dependencies). Based on what you find, you can get the entries for Local::Foo::Bar and Local::Foo::Baz (things used by Local::Foo) or perhaps Local::Stuff (which uses Local::Foo). Then you can examine those records, etc. This is how ...::Grapher builds the tree of dependencies, basically.You use Module::Dependency::Info to get at these records using a nice simple API. If you're feeling keen you can just grab the entire object - but that's in the ...::Info module. Here we have a single index for all our local perl code, and that lives in /var/tmp/dependence/unified.dat - the default location. Other applications just use that file. DEBUGGINGThere is a TRACE stub function, and the module uses TRACE() to log activity. Override our TRACE with your own routine, e.g. one that prints to STDERR, to see these messages.SEE ALSOModule::Dependency and the README files.VERSION$Id: Indexer.pm 6643 2006-07-12 20:23:31Z timbo $
Visit the GSP FreeBSD Man Page Interface. |