On Jun 10, 2004, at 6:06 PM, John Horner wrote:
This may be a frequently-asked question, but I've got installed
modules which CPAN says are up to date but Perl can't find.
@INC contains:
/System/Library/Perl/5.8.1/darwin-thread-multi-2level
... snip ...
but when I look for HTML::TokeParser, I find it in
/Library/Perl/darwin/HTML/TokeParser.pm
/Library/Perl/darwin is the architecture-specific directory for Perl
5.6 on Jaguar and older. Modules found there will not be compatible
with the 5.8.1 version of Perl that you're using.
so what should I do? I can't see exactly how CPAN (or a previous
version of it) decided on that as the install location -- can I change
the Config for CPAN to fix that?
A previous version of Perl (correctly!) decided on that, not a previous
version of CPAN. (The difference is a bit academic, I know, because
CPAN.pm is bundled with Perl...) You cannot fix it because it is not
broken.
I know, of course, that I can have use lib to add that to @INC for
each script, and I could presumably hack that for the Terminal
environment somehow, but I'd rather not -- can I force that into @INC
in some kind of system-wide way?
You could, but that wouldn't allow Perl 5.8.1 to use modules compiled
for 5.6. There is a reason that some modules are kept in version- and
architecture-specific directories - they don't work with other Perl
versions or architectures.
One more question, sorry -- if I just copied the TokeParser.pm into
the right dir, somewhere Perl *is* looking for it, would that be a
problem?
Yes. For one thing, there's more to this module than just the .pm file
- there's also a .bundle, and there might be some autoload (.al) files
or affiliated module (.pm) files as well.
Assuming that modules are pure-perl
That's an invalid assumption. The architecture-specific subdirectory
exists for the purpose of providing a separate location for modules
that are *not* pure-perl. Since HTML::TokeParser is in that directory,
you should assume it's *not* pure-perl, but has an XS (i.e. a compiled
C) component as well as Perl.
Modules that are compiled for different major versions of Perl (5.6 vs.
5.8), and/or for different architectures (darwin vs.
darwin-thread-multi-2level) are *not* compatible with other versions
and/or architectures. So even if you did go to the trouble of figuring
out what files to move, moving them wouldn't do any good.
I should just reinstall?
I'd use a scalpel first, and save the axe for a last resort. ;-)
The key question is why the CPAN tool is claiming that this module is
up to date when in fact it is not. How are you starting it, with 'cpan'
or with 'perl -MCPAN -e shell'? Whichever one you're using, try the
other to see if you get the same results. Is there a PERL5LIB in your
environment?
That's key - you need to understand that the module is *not* in an
incorrect location. It's in the correct location for the Perl it was
installed under, and your current Perl avoids looking in that location
for a good reason. Nothing is broken in that regard. What you need to
figure out is why the CPAN shell is finding that module when it
shouldn't.
sherm--
