Please note that even after adding a new installation, configs of an old one can interfere. They must be purged.
| [reply] |
| [reply] [d/l] |
I am not sure what "I build the customized perl version with required packages" in the context of "ActiveState old perl version 5.8.8? The new AS customized build process doesn't work with Perl versions that old so I am not sure what you mean?
I am currently on AS 5.24 (the last release using PPM-Perl Package Manager). Although I have not transitioned my setup to the new AS way due to lack of need, but I have successfully made some custom builds that others have installed.
My free account is limited I think to 2 forks. If you don't mind some bloat of a fair amount more than just Tk added past normal "out of the box" modules, I can revisit my main Tk fork and re-build and send you the download link. This is the new way that an AS installation starts. The build process happens on Active State's cloud servers and this process is way, way faster than anything you could do on a single machine. All dependencies and tests are satisfied.
Once the build is installed (a very fast process), you can also add modules in a way similar to what you used to do with PPM, just with a different set of tools. Of course using CPAN for installation of additional modules is possible, just like it always has been. I have cpan installed on my AS Perl 5.24 build and I also include it with my forks of new AS builds. However, under normal circumstances using the AS tools is faster and involves less hassle - resort to cpan only if the normal way doesn't work and usually that means you will have to fix a build problem yourself.
I am not aware of any custom build process for Strawberry that is equivalent to Active State's process. There used to be a process where after installation of the standard release, you ran a tool that took an XML file and installed all the modules in that file. Unfortunately for complicated reasons, this didn't always result in identical installations. I could not reliably clone my installation in a legal way without copyright violations. Now that is possible and is one of the reasons AS changed their process.
Moving from ancient AS Perl to modern AS Perl or to Strawberry probably means that you have to thoroughly remove all remnants of the existing installation including bogus paths. The AS install scripts are now pretty good and moving forward, they are designed such that a new version can be installed on top of an old version. That did not used to be the case!
Anyway, let me know if you want my AS Tk build.
| [reply] [d/l] [select] |
By default the strawberry perl path is not added into PATH env variable
Are you sure?
I've installed Strawberry Perl a couple of times recently. One Windows 10 desktop and one Windows 11 laptop. In neither case did I have to set the PATH variable. I did have to change the association of *.pl and *.pm from perl.exe to a text editor.
I'm not near either of those machines right now. But this Windows 10 machine has Strawberry Perl installed and there are 3 Strawberry Perl paths in PATH. It was installed a long time ago but I don't recall setting PATH manually.
| [reply] [d/l] [select] |