Eric Wilhelm wrote:
# from misoldgit
# on Friday 18 May 2007 01:55 am:
So my question really is, I guess, why isnt pp picking up all the
dependencies from the get go and what is missing (do I have to
manually add it). All of a sudden this is not so easy.
Depending on how many modules you're pulling in and when, no it isn't
easy. Module::ScanDeps does static, compile-time, and runtime
scanning. If your frontend doesn't load everything at compile-time
(some backends delay loading and/or depend on non-module files), then
it gets trickier. Consider though that the time required to scan a
large program is quite large. You may also have to tell it to package
some .so files from /usr/lib or whereever.
As a workaround, if you prepend a BEGIN {require foo; require bar;...}
block to your program, pp will see everything there and you don't have
to keep typing it on the command line. Packaging dotReader in a par
quickly became non-trivial, but that complexity is captured in the
Build code. I would like to see Module::ScanDeps do a better job, but
at large scales, it starts to be important to cache the dependency
list, etc.
The DWIM usage works fine for small scripts, but it actually generates
an overkill package in a large program (e.g. Log::Log4perl will cause
Module::ScanDeps to decide that you need DBI unless you tell it
otherwise.)
--Eric
> BEGIN {require foo; require bar;...}
This sound pretty good. I would only require the ones that were
suspect. That is, not in a "use" statement in main, or in a file that
is "use'd" directly by main, or, etcetera along the directly "use'd"
paths from main. ScanDeps should be picking them up.
I ran into an esoteric problem once because of pulling in a module too
early. I bring it up only to demonstrate that there is at least one
possible reason for not pulling in a module too early, and to suggest
that there could be others. I will briefly describe only the root cause.
In a certain installation program (read: done only once) I do a fork. I
have to make sure I do not "use Tk" until after the module that does the
fork (and handles the child) because Tk is not thread safe. The problem
went away after I relocated the "use Tk" to after the file fork/Tk
combination.
Good luck
