On Sun, 18 Jun 2006 19:50:30 -0500, Ken Williams wrote:
Hi Ken
Thanx for the quick response.
I'm in Melbourne (Aust, not Florida). Do you work 24x7 or are you in a similar
(i.e. civilized :-) timezone?
> Because of this entry in the "Changes" file:
Fair enough. I did not notice that.
>> o Why did it not delete the previous version, given I used: perl
>> Build install uninst=1
>>
>
> Probably because my-lib/lib wasn't part of your @INC.
> Module::Install searches your @INC for other copies to delete.
Nope. The install program contains:
use lib "$ENV{'INSTALL'}/lib";
and has - I'm /pretty/ sure - from the year dot.
I either use that line or the full path to the same lib dir in all main
programs, since (on this GNU machine) I do not have permission to install into
the 'usual' dirs. And no, I don't use PERL5LIB except when trying to diagnose
problems such as this. Seems pretty clear to me. I'll just write it off as
another quirk of V 5.8.0.
So I guess the options are:
o use lib "$ENV{'INSTALL'}/lib/perl";
and uninstall and reinstall all modules so they all go into lib/perl5
or
o Leave installed modules and have the home-grown installer and all other main
programs use both
use lib "$ENV{'INSTALL'}/lib";
use lib "$ENV{'INSTALL'}/lib/perl5";
Or am I missing something obvious?
Now under Windows:
BTW: I found another module, ExtUtils::Install, where Module::Build V 0.2801 did
not uninstall the previous version. I uninstalled it by hand. I did notice that
earlier version of ExtUtils::Install was installed in /perl/lib/ and did not
have a .packlist file. Is that what M::B uses to find what to uninstall?
Also, the new version installed into /perl/site/lib, and not
/perl/site/lib/perl5 (having regard to the change you quoted), because (under
Windows) I don't use install_base and everything just works. Sigh. Another
complication :-(.
--
Ron Savage
[EMAIL PROTECTED]
http://savage.net.au/index.html
