On Wed, Nov 12, 2003 at 09:21:35PM +0800, Autrijus Tang wrote:
> ?b ???, 2003-11-12 13:18, Edward S. Peschko ?g?D?G
> > a) wrapping the whole script in a an anonymous sub
> > b) using the perl interpreter to run all the 'startup code'
> > c) extracting the evaluated module list from '%INC'.
> > d) passing the results to Module::ScanDeps
>
> Module::Info is right down the hall, third door on the left. :-)
>
> > If a patch is acceptable, what would be the best thing to patch? PAR or
> > pp?
>
> Patching Module::ScanDeps to optionally yield extra results via
> Module::Info sounds okay. Otherwise, patching pp to use the App::Packer
> interface is another way to go.
Do you control Module::ScanDeps? I looked through Module::Info, and that requires
B::Utils. In addition, Module::Info has the following limitations:
1) uses optree to find information, not runtime info
2) can't find modules inside an eval
3) code refs in @INC are currently ignored.
It has a 'packages_inside' function, but even that has known bugs (no package changes
inside subroutines, evals, etc).
In other words, through the B::Utils you risk all sorts of malapproprisms. App::Packer
not only requires Module::Info, but a hacked verswion of Module::Info. It also seems
to
do analytical packing as the method for storing dependencies.
I wouldn't mind writing an interface, Module::Info::Runtime, that follows the
Module::Info interface, and maybe bundle it with Module::Info. That seems the
quickest way to go:
1) optionally let Module::ScanDeps use Module::Info if wanted
2) optionally let Module::ScanDeps use Module::Info::Runtime if wanted
based on a flag. Module::Info really does a totally different thing that what I'm
after.
Ed
