Hi, I have a problem which is slightly off-topic from a "pure PAR" perpective, but as it affects PAR build size (and time), someone of the PAR community might have a solution/idea/comment. The problems described below don't hurt that much for PAR building, but do cause lots of overcautious "uses" indications when trying to build a module dependency graph.
As an example, take the SOAP::Lite module, which uses SOAP::Transport::HTTP,
which uses URI, which uses URI::*,
which then may use e.g. POEx::URI (if installed).
SOAP::Transport::HTTP contains a few packages itself - one example is
SOAP::Transport::HTTP::FCGI, which requires FCGI -
as a consequence, FCGI will automagically end up on the "uses" list of
SOAP::Transport::HTTP.
Phenomena found with Module::ScanDeps 1.07:
First, I have found that Module::ScanDeps::scan_deps (with recurse =>
0) also list included usage,
at least if all Perl modules in the hierarchy are being parsed.
Regarding the above example, that means SOAP::Transport::HTTP is
claimed to directly use the URI/*.pm stuff.
Second, the _glob_in_inc functionality simply causes all *installed*
files being marked as "used" -
regarding the URI/*.pm example, this brings in POEx::URI, which will be
never needed unless I really use poe:// URLs.
The main difference between URI/poe.pm and most other URI/*.pm
submodules is that URI/poe.pm does not belong
to the URI package (information can be derived from .packlist).
This leads us to the insight that there are "strict" uses, and
"facultative" ones.
Third - revisiting the FCGI example from above.
Package SOAP::Transport::HTTP::Server (in file
SOAP::Transport::HTTP.pm) also states "use URI;",
and then URI seems to be actually used in a subsequent package
(SOAP::Transport::HTTP::Daemon) in that file ...
The difference between this strict [mis]use and the FCGI example is
that FCGI use will be definitely only in scope
as a dependency of the SOAP::Transport::HTTP::FCGI package - if that is
ever used.
Here the insight is that dependencies happen on package level, not on
module level.
Summary trial: Perl dependencies are created on package level, where packages
happen to be implemented in modules
(not always "their" one and only), and modules happen to be delivered via
distributions (also sometimes more than one).
For serious dependency studies, "uses" should give a hint whether the actual
usage is strict of facultative. Anything inside an eval
could be seen as facultative. [PAR should pack facultative files of the same
distribution.]
Thus, I wonder whether the present Module::ScanDeps parsing touches a wall (or
ceiling) - in other words, whether it would make sense
to deploy the parsing job to e.g. something PPI based. Without a decent
hierarchy tree based view of a Perl module,
parsing might become a nightmare.
Any opinions / remarks / contradictions are highly welcome ..
Cheers,
Markus
P.S.: Related problems on top are that META files (if they are present and
complete) don't get installed, and the .packlists
might contain outdated / deleted(moved) files, and the @INC tree might
contain both outdated and new versions ...
MARKUS JANSEN
Ericsson Deutschland GmbH
Ericsson Allee 1
52134, Herogenrath, Germany
Phone +49 2407 575 5157
Fax +49 2407 575 14761
Mobile +49 172 2742003
markus.jan...@ericsson.com
www.ericsson.com
http://www.ericsson.com/
Ericsson GmbH. Sitz: Düsseldorf. Registergericht: Amtsgericht Düsseldorf, HRB
33012. Geschäftsführer: Stefan Koetz. Aufsichtsratsvorsitzender: Anders Olin
This Communication is Confidential. We only send and receive email on the basis
of the terms set out at
www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>.
<<inline: Picture (Metafile) 1.jpg>>
