ACTIVEPERL VS STRAWBERRY PERL WINDOWS
Now, I am also occasionally using Perl under Windows (perhaps only 5 to 10% of my Perl activity). it is much more compatible with the rest of my work under Unix. because the Unix shell, whether sh, ksh or bash, is so vastly superior to the DOS cmd that there is not even room for discussion 2. And even on Windows, my favorite Perl environment is Cygwin. Especially in view of the fact that I am using Perl mostly (and by far) on Unix/Linux systems. Hmm, not sure that I should try to say something relevant after the excellent, detailed and well-argumented answer by davido. The 32bit version of ActivePerl has a PPM for installing all the build tools you need to use cpan properly. Re^2: Advantages of Activeperl vs Strawberry Perl *For the most part, excluding things like Win32:: on *nix. There is no reason those scripts can't run on a Strawberry Perl installation or vice versa (your scripts run on an Activestate distribution). "the Perl Scripts running in production environment use Activestate" statement I'm assuming means that Activestate is the Perl that is loaded on the production machines to run the scripts. It was much easier to just go to CPAN like I do on every other version of Perl. I found Activestate's autobuild process lacking and not all PPM's were available. I moved TO Strawberry from Activestate about 5 years ago because Strawberry comes with a C-compiler (gcc) and therefore - in my experience - has the ability to run more CPAN XS modules than Activestate. Perl is Perl so scripts written in Perl will run with Activestate, Strawberry and/or any *nix version*. To answer that I'll refer you back to the first line of your post as evidence: For those who are more open to the Perl way of doing things, both ActivePerl and Strawberry support that now.ĭo organizations prefer or care if I use ActiveState or something else? For those PHB's that value the support contract, PPM is probably still a necessity. Nowadays, ActivePerl also supports user compilation of modules, including XS modules, and the PPM utility becomes a little redundant. This really was Strawberry Perl's niche originally that someone familiar with the Linux/Unix way of doing things with Perl would be able to use the standard Perl tools in building modules.
ACTIVEPERL VS STRAWBERRY PERL INSTALL
Strawberry packaged the gcc compiler and 'make' along with Strawberry Perl, which allowed users to take advantage of the standard Perl toolchain in installing CPAN modules the CPAN installers, or just downloading the tarball, unpacking it, and performing the make, make test, make install mantra. This was because historically modules required the extremely elusive Microsoft utility, "dmake" to be built out, and if a C compiler was required (for XS modules, for example), it was even less likely that a given system would be equipped with the necessary tools. Years ago, ActivePerl packaged up many of the popular Perl modules into ".ppm" distributions that could be installed using the ppm package manager. I think many times it kind of goes along with the mindset of "Nobody ever gets fired for choosing to start a project using Java." In other words, it looks good on paper.įrom a practical standpoint, the primary difference between, say, ActivePerl and Strawberry has become less significant over the years.
In practice each organization has to evaluate whether the peace of mind of a support contract, and the support it provides are things that they need. Nowadays one of the main reasons to be using it is the ability to buy a support contract, which mostly is there to satisfy PHB's and other managerial folks who sleep better at night knowing that when something breaks their bosses won't fire them for using a "community supported" version of Perl.
Now we get to the interesting part of the question. Outside of your organization there are many who do use other flavors of Perl in production, many self-compiled/managed.Īll the scripting work I have done are Windows Test/Certification Servers which don't have any production apps running on them.Īre there any advantages of using Activestate Perl? Possibly within your organization that's true. Infact he stated that all the Perl Scripts running in production environment use Activestate. But a support contract is one reason that an organization may prefer ActivePerl. Not all organizations gravitate to ActivePerl - some self-manage, some use RedHat, etc. a lot of organizations prefer using ActivePerl because it has commercial support.Īssuming those organizations are purchasing a support contract from ActiveState, this may be true. I was told by a senior at work to start using ActivePerl on Windows. Re: Advantages of Activeperl vs Strawberry Perl
0 kommentar(er)
