On Windows, you could always (or at least since Perl 5.6.1) take the Perl directory and move it wherever you like. You only need to update CPAN/Config.pm, but Perl.exe would still find all relevant directories, like lib/ and site/lib, as long as Perl.exe resides in bin. On older operating systems, especially the Unixish variant, all the directory paths are hardcoded in the perl executable, and thus you will encounter various problems should you move the Perl libraries from (say) /opt/perl/ to /usr/local/perl/ without recompiling or patching your perl executable.
I'm happy that Nick works on bringing Unixish systems up to par with Win32-based systems!
| [reply]
[d/l]
[select] |
And hopefully CPAN.pm will then follow suit, so you eventually you won’t have to change its configuration either.
Makeshifts last the longest.
| [reply] |
... like lib/ and site/lib, as long as Perl.exe resides in bin....
As long as bin isn't under a directory with a name of the form 5.6.2, as I explain in Re: How is the default @INC constructed? :)
| MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] |
It would obsolete PAR for some purposes, but more importantly it would open up scenarios far beyond what PAR can address. A relocatable perl binary would allow distributable installations which can be updated trivially using CPAN.pm, without any configuration work. This could be a great boon to shared hosting, f.ex.
Makeshifts last the longest.
| [reply] |