On Mo. 16. Okt. 2006, 03:59:33, JV wrote:
Show quoted text> [Quoting Steffen Müller via RT, on October 15 2006, 16:59, in
> "[rt.cpan.org #22115]"]
> > return $1 if /\b(\w[\w:]*)::\w+\(/;
> >
> > That picks up any strings of the form "Foo::Bar::baz(" and takes
> > "Foo::Bar" as the namespace of a module to require.
>
> Why? I'd say only 'use Foo::Bar' or 'require Foo::Bar' validates the
> inclusion of module Foo::Bar. If a module uses Foo::Bar without
> including it, there must be some other module that includes Foo::Bar,
> otherwise we are dealing with an application that is inconsitent.
I'm not going to defend Module::ScanDeps' approach because neither did I
craft nor implement it. But I'll point out that you're missing something
here: Perl programmers have been very, very good at creating devices to
defeat anything that tries to parse portions of the code. How about this:
use Scary::Device;
Scary::Device->LoadPlugins(qw/Scary::Device::Plugin::Foo/);
And trust me: This is just *one* of the cases relying on "use" and
"require" fails.
I think the idea behind M::SD's heuristics was laid on that foundation.
It picks up anything that might be a module and sees whether that module
exists in the library. If it does, it assumes it found a valid
dependency. It's bad that way, but users are generally much more annoyed
if a dependency is *not* picked up than if a dependency is picked up too
much. In case of Tk, however, that's a *lot* that's picked up. Again, in
parts because Tk has the weirdest auto-loading mechanisms of them all!
Adding a quick workaround to Module::ScanDeps' scan_line or scan_deps
routines would be possible. I can do that within a couple of days.
Rewriting ScanDeps with a better approach is for somebody else.
[...]
Show quoted text> Module Blech depends on Foo, but not on Foo::Bar. It does, indirectly
> via Foo, but not directly.
I understand that.
Show quoted text> > I don't know how to proceed. It would be easy to add a statement
> > akin to "if this is Term::ReadLine, I'm scanning, don't pick up any
> > Tk dependencies!", but that's a bad hack stacked on top of another.
> > I would hope Audrey could chime in on this.
>
> For this particular case, I'd be happy if I could override the
> inclusion of Tk. Unfortunately, the command line switch -X Tk does not
> have this effect.
>
> Either Module::ScanDeps or PAR needs a more extensive way to control
> what gets included (and excluded) anyway. PAR.yaml, maybe?
Hmm. I was going to suggest -X Tk. Perhaps -X Tk actually excludes it
but not its dependencies (which are found to be Tk::*)? I just checked
it and that seems to be the case. Why? My hunch is that pp's -X excludes
a specific module *after* the scanning has taken place. That means: The
tree generated while scanning isn't pruned while scanning but a node is
removed afterwards. I agree that this is the wrong behaviour. I am
unsure how difficult it would be to implement the (more) correct
behaviour. For the lack of time, I can't do it now. I cannot make any
promises either.
In general, though it won't help here, you can put any series of command
line arguments into a text file and do
pp @textfile
to use it as the source for parameters if the list is too long.
Show quoted text> BTW: Are there any known quirks with the processing of INIT blocks? I
> have an app that loads a particular module and starts the main code.
> When run, it show the following debugging messages:
>
> == (module BEGIN block execute)
> == (module code execures)
> == (module INIT block executes)
> ... application runs ...
>
> However, when PARred, I get:
>
> == (module BEGIN block execute)
> == (module code execures)
> ... application runs ...
> == (module INIT block executes)
>
> It's a big application so it is not easy to track this down. But maybe
> there are some known issues that can help me finding (and fixing) it.
IIRC, this is absolutely an issue. Have a look at the TODO list,
specifically the last item of the original list:
http://par.wikia.com/wiki/DevelopmentInProgress
It talks about check blocks, but IIRC, that applies to INIT blocks as
well. I do not claim to understand the issue, though. You will have to
try to get Audrey involved for that.
I have been bitten by this before. I think some of the attribute modules
use check/init blocks. Good luck tracking it down!
Show quoted text> BTW2: (Sorry, can't stop) I always install modules in a private
> library. But despite my CPAN::MyConfig settings PAR insists on writing
> to the system perl library. Is this a Module::Install versus MakeMaker
> thing? I'd be willing to make an issue for it, but I'd like to check
> it first.
Perhaps the Module::Install auto-install feature does that? I.e. it asks
whether it should install Module::Foo now (before PAR) because it's
missing for feature Bar? If you say yes to that, it's outside CPAN
because it's done by the bundled Module::Install. I think that is the issue.
Adam Kennedy has been hacking on the PAR Makefile.PL a bit to remove the
M::I auto-installation and feature stuff in favour of a sane build
process. I would hope this last problem goes away when that is released.
(Still chasing him so he commits it.)
Steffen
RT for rt.cpan.org