Hi Steve,
sorry for replying so late.
Steve Hay schrieb:
> It first broke in 0.74, and the change that breaks it is the following
> change to Module::ScanDeps::scan_deps():
>
> --- Module-ScanDeps-0.73/lib/Module/ScanDeps.pm 2007-03-25
> 19:18:22.000000000 +0100
> +++ Module-ScanDeps-0.74/lib/Module/ScanDeps.pm 2007-04-30
> 19:42:42.000000000 +0100
> @@ -445,6 +451,18 @@
> (@_ and $_[0] =~ /^(?:$Keys)$/o) ? @_ : (files => [EMAIL PROTECTED],
> recurse
> => 1)
> );
>
> + if (!defined($args{keys})) {
> + $args{keys} = [map {_path_to_filename($_)} @{$args{files}}]
> + }
> +
> + my ($type, $path);
> + foreach my $input_file (@{$args{files}}) {
> + $type = 'module';
> + $type = 'data' unless $input_file =~ /\.p[mh]$/io;
> + $path = $input_file;
> + _add_info($args{rv}, _path_to_filename($path), $path, undef,
> $type);
> + }
> +
> scan_deps_static(\%args);
>
> if ($args{execute} or $args{compile}) {
> End of Patch.
>
> Any ideas what that change is trying to do and why it has broken the
> finding of DBI.dll in a command such as "scandeps -V
> C:\perl5\site\lib\DBI.pm" ?
I have contacted the author of that change, Adrian Issot, but it seems
he is busy these days as I haven't received an answer so far.
I just had a quick glance at the code and there seem to be a couple of
things that might go wrong. I can't claim I understand all of
Module::ScanDeps without spending a lot of time.
*However*, I can do some wild guessing. Adrian introduced the
_path_to_inc_name subroutine intended to make all Perl modules that are
found unique in the sense of "/foo/bar/Module/Something.pm" and
"/hi/there/Module/Something.pm" being both mapped to "Module/Something.pm".
The subroutine is around line 456 of the following view of the source:
http://rt.openfoundry.org/viewvc/Module-ScanDeps/trunk/lib/Module/ScanDeps.pm?annotate=468&root=par
In the newest revision, Adrian uses Module::Build::ModuleInfo to do this
for the .pm files. I'll just suppose this works okay. However, for
non-module files, he just uses the file's basename as a unique
identifier. I would say that's bound to fail in some cases. I'm not sure
whether that's related to what you're seeing or not. Certainly, it can't
be just this or otherwise "DBI.dll" would still work as identifier.
I don't have *any* win32 any more, so I can't do actual bug hunting and
my head isn't so great at executing Perl code :(
I would suggest putting a debug statement into _add_info to see what
happens to DBI.*.
Best regards,
Steffen
