Not that I'm suggesting that you should avoid perlbrew. It's widely used and generally recommended - from which I deduce that it's reliable and user-friendly. (I've never even looked at it, so I don't know.)
Probably its main advantage is that it makes switching between Perl installations easy; it takes over modifying PATH etc. so that you can switch between the system Perl and the Perlbrew installed Perls either for the current session or for all future sessions easily. It also can make use of Devel::PatchPerl (especially useful for installing older Perls), and has a command that installs cpanm. But as you said, doing a manual install into one's home directory is fine too of course.
| [reply]
[d/l]
[select] |
Probably its main advantage is that it makes switching between Perl installations easy
That can also be easily accommodated with shell or batch scripts. (I guess that's just a homespun, poor person's Perlbrew ;-)
In any case, I don't find it a great hassle to run export PATH=~/blead-5.31.7/bin:$PATH
There are, however, traps for the unwary in simply pre-pending another perl to the path.
For example, what happens when you then run cpan -i Some::Module and the first perl in the path doesn't have a 'cpan' utility (because it's named 'cpan5.31.7') but the next perl in the path does have a utility named 'cpan' ?
IIRC, I eventually learned that I should always build blead with '-Uversiononly'. That way, the cpan utility will be named 'cpan'.
(The same issue also existed wrt other utilities if '-Uversiononly' was omitted.)
On Windows, when I switch to a different version of perl, I generally need to switch to a different version of gcc (also handled by the same batch script).
This is because, on Windows (for me, at least), each build of perl has a runtime dependency upon the gcc installation that built it.
Perl versions 5.8.8 through to 5.18.0 were built with gcc-4.7.0, followed by others built using gcc-4.8.2, gcc-5.3.0, gcc-6.3.0 or gcc-8.1.0.
Therefore, switching to another version of perl can often necessitate switching to another version of gcc.
I'm not sure that, even if Perlbrew had built these perls, it could handle the required switching of compilers ??
Come to think about it, I don't actually know if Perlbrew can be used to build perl on Windows at all. (I suspect not.)
Cheers,
Rob
| [reply]
[d/l]
[select] |
(I guess that's just a homespun, poor person's Perlbrew ;-)
Sounds like it :-)
For example, what happens when you then run cpan -i Some::Module and the first perl in the path doesn't have a 'cpan' utility (because it's named 'cpan5.31.7') but the next perl in the path does have a utility named 'cpan' ?
Yes, that's a good point, that's what I meant when I wrote to check which perl vs. which cpanm. It's also why I recommended cpanm, because as long as you point its installation (curl -L https://cpanmin.us | perl - App::cpanminus) to the correct perl binary, it should get installed in the correct bin directory.
I'm not sure that, even if Perlbrew had built these perls, it could handle the required switching of compilers ?? Come to think about it, I don't actually know if Perlbrew can be used to build perl on Windows at all.
No, but stevieb's berrybrew can. Each distro of Strawberry Perl comes with a compiler, and berrybrew also switches the PATH entries for those as well.
| [reply]
[d/l]
[select] |
