Strawberry Perl is "Open Source Perl for Windows that is exactly the same
as Perl everywhere else". Vanilla Perl "provides a Perl distribution that is as close to the Perl core as possible." Strawberry Perl is built on Vanilla Perl.
Both distributions come with a C compiler so that perl modules from CPAN that use XS can be built.
What are the differences between Strawberry Perl and Vanilla Perl?
Just read the explanation on the Vanilla Perl homepage
Vanilla Perl Series
The Vanilla Perl series provides a
Perl distribution that is as close to
the Perl core as possible. If
necessary, it may include
win32-specific fixes.
Vanilla Perl is experimental and is
not intended for production purposes.
It is targeted to master-level Win32
Perl developers and those who wish to
experiment with building their own
custom Win32 Perl distributions.
Vanilla Perl releases are numbered
only as sequential 'builds' and will
not follow any alpha/beta/release
plan. This means incremental builds
may be less stable than previous
builds as new release configurations
are tested.
And
Strawberry Perl Series
The purpose of the Strawberry Perl
series is to provide a more practical
Win32 Perl release for experienced
Perl developers to experiment and test
the installation of various CPAN
modules under Win32 conditions, and to
provide a useful platform for
experienced Perl developers to start
doing real work.
In addition to the modules in Vanilla
Perl, Strawberry will also include the
entire dependency tree for
Bundle::CPAN, as well as an additional
set of upgraded versions of dual
CPAN/core modules that have
win32-specific fixes.
The answer is that often Perl distros come with non-core modules. ActiveState in particular is known for doing this. The non-core modules improve usability quite a bit.
Vanilla is the core distro. Strawberry comes with the standard non-standard modules. ;-)
As per Vanilla Perl home page:
In addition to the modules in Vanilla Perl, Strawberry will also include the entire dependency tree for Bundle::CPAN, as well as an additional set of upgraded versions of dual CPAN/core modules that have win32-specific fixes.
From Wiki:
Strawberry Perl is part of the Vanilla Perl Project
Related
I want to use Perl for web development. I have tried to find out how to install it but when I tried to get ActivePerl it wouldn't install on Windows 8. Can anyone tell me how to install Perl on Windows 8? I can go for ActivePerl, Strawberry Perl, or any other Perl release as long as it will work on Windows 8.
As you already know, there are two generally used Perls in the Windows World:
ActivePerl from ActiveState.
Strawberry Perl which is an open source project started by Adam Kennedy -- a big honcho in the Perl community.
What's the big difference between them:
ActiveState Perl was designed to be a Perl solution specifically for Windows (and later both Macs and Linux). ActiveState offers a very nice Perl IDE called Komodo and has excellent Perl support. All you need is some cash. After all, that's how ActiveState makes its money. Of course, you can use EPIC instead of Komodo and get a lot of help from StackOverflow too.
ActiveState comes with the default Win32 modules already installed and also supplies a Perl Package Manager (PPM) instead of using CPAN for installing other CPAN modules. PPM has a nice GUI interface, and its modules have already been precompiled and tested. It also is a bit better than CPAN with dependency tracking. Of course, there might be some CPAN modules not in PPM, and that can be an issue.
Strawberry Perl was started to be more Open Source oriented than ActiveState. By default, Strawberry Perl comes with a Make program and a complete development environment, so that almost all CPAN modules are available and can be installed. This is because Strawberry Perl comes with the complete MinGW package which includes Make and a gcc compiler. The idea was to give Perl people who mainly use Linux and Unix machines a similar feeling solution for Windows.
In reality, both are pretty similar. ActiveState comes with the Win32 modules, but you can install them as needed on Strawberry Perl via CPAN. Strawberry Perl works with CPAN, but ActiveState gives you complete directions for installing the same MinGW environment that Strawberry Perl uses (via their PPM) which allows you to install all CPAN modules that Strawberry Perl can install. ActiveState comes with a GUI Perl Documentation that includes all installed Perl modules, but the perldoc command gives you the same information anyway.
So, if you're more Linux/Unix oriented and want something that feels very similar on Windows, go with Strawberry Perl. If you are using Perl as a Win32 solution, go with ActiveState. And, don't worry about choosing the wrong one. In the end, Strawberry Perl can include all those nice Win32 modules, and ActivePerl can use CPAN.
There is another SO posting that you might find what you're looking for here. A similar posting. In sum, I get the impression that Strawberry Perl would work alright, and so would ActivePerl. I rather liked Strawberry Perl, and it was so long ago that I installed it on my wife's Windows Vista machine that I can't remember why I chose it over ActivePerl, ymmv. CHEERS!
I've done some research and it seems like ActivePerl had issues with earlier releases of it's product with certain CPAN modules not installing properly. However, I'm running the 5.14.x version and I've not had any problems.
According to some quotes I've seen:
ActivePerl is 100% compatible with the reference distribution of Perl.
Code tested with ActivePerl will run on any Perl installation that has the appropriate extensions installed.
I assume that the first statement refers to the standard modules you get with the Perl installation and for the second, I'm not sure what they are saying?
In any event, is there any way to find out how compatible ActivePerl is with the current CPAN modules or is that something that isn't known? I just don't want to spend time with it, only to have to switch to something like Strawberry Perl next month to avoid CPAN module build failures for the more common modules.
If ActivePerl is compatible with say 80% or higher with the CPAN modules I would feel more comfortable about using it, but I couldn't find any information on this.
I doubt a generic statistic will be that useful. In general I would expect all "pure perl" modules should work more or less out of the box. Keep in mind however that certain perl modules really are interfaces to lower level linux/unix style shared libraries (dlls in Windows terms), where availability is less certain. In my experience (having written a few perl applications being hosted on Windows, against my advice) most things will work, and/or are fairly easy to work around, and both ActiveState and Strawberryperl seem to have decent support for most common modules.
The first statement doesn't refer to modules at all. It says that ActivePerl is not based on Perl, it is Perl. As such, anything that will run on Perl will also run on ActivePerl.
This also means that all modules on CPAN are compatible with ActivePerl since ActivePerl is Perl.
Whether a module is compatible with Windows is an entirely different question, and it can only be answered on a module-by-module basis.
The second statement points out that if you had a script or module that runs on a pristine ActivePerl, it might not necessarily run on a pristine Perl because ActiveState includes modules in its distribution that aren't core modules (e.g. LWP). But all you'd need to do to make the script or module run on the other distribution is to install those modules.
You can check on the availability of PPM modules at http://code.activestate.com/ppm/. For example, one module that doesn't work well through PPM is PAR::Packer.
What is a "dual-life" module? It's mentioned in the perldelta for Perl 5.14.
Dual life modules are modules that exist in two disconnected source repositories, commonly meaning both in the Perl core (those libraries distributed with perl), and on CPAN.
The CPAN version may be updated more frequently than the core version. The core version may have been tested on more platforms.
In the context of the link you gave, "adding as a dual-life module" means forking the CPAN distribution, possibly making some changes (such as normalizing documentation or licensing), and incorporating that fork into the core perl repository. This means that this module will now be installed by default when anyone installs this version of perl.
A dual-lived module is one that is found both in the perl distribution and in its own distribution (on CPAN). For example, Data::Dumper is part of the perl distribution and the Data-Dumper distribution. On the other hand, IPC::Open3 is only available as part of the perl distribution, so it's not dual-lived.
The advantage of a dual-lived module (these and these) is that it can be upgraded without upgrading Perl.
If you wanted to upgrade a core module that isn't dual-lived (these), then you have to upgrade all of Perl.
I'd like to install a Perl module (in this case, FindBin), but since it is included in the Perl 5.10.1 distribution, cpan wants to install Perl 5.10 for me. Is there a way of installing just the module via cpan?
The only option that I can see is installing directly from source, which seems a bit crude as there is no separate package (for example, Makefile.PL, etc.), just the bare .pm file.
Since this is a small module that only has the one file, it's doable in this case, but what if I wanted to install a much larger package?
EDIT: This is somewhat aside from the original question, but speaks to the general issue of modules being packaged up with Perl distributions: I discovered that the "standalone" FindBin (version 1.49) had a syntactic error, so I retrieved version 1.50 out of the Perl 5.10.1 distribution... However since the module is now listed on CPAN as part of Perl 5.10, I am unable to find the CHANGES file describing what was changed/fixed in this delta. Is it reasonable that I should have to go into the developer repository to pull out this information?)
EDIT 2. Okay, here's a better example. On Perl 5.8.8 I have version 1.04 of Carp. However, I see that Perl 5.10.1 comes packaged with version 1.11. Is there a way of getting CPAN to install the latest version of Carp for me without dragging in all of Perl 5.10.1? I can't even find a link to the Carp module on CPAN except to the perl 5.10.1 installation.
> corelist FindBin
FindBin was first released with perl 5.00307
Which version of Perl do you use that does not include FindBin? If you use at least Perl 5.6.0 (all versions before are considered deprecated), you have no need to install FindBin. If you have anything older, I suggest an upgrade to 5.6.2/5.8.9/5.10.1.
Kurila is not a "standalone" FindBin, it's a dialect of Perl. FindBin is not a dual life and is released only bundled with Perl. You can consider releasing FindBin to CPAN as standalone distribution - it is easy if you used ExtUtils::MakeMaker in past.
Latest useful change of FindBin was on 2007-04-28, related to VMS. Latest useful non-VMS change was on 2006-10-25.
Things you can try include
Dropping FindBin.pm into the same directory as your executable and using use FindBin
Dropping FindBin.pm into your Perl library directory
Using the source code of the module in your script
I am looking at embedding perl 5.10 in a large C++ application compiled with VC++ 6.0. This leads to two questions.
1) Is it a bad idea to simply use Strawberry Perl as a dependency rather than compile my own perl with VC++ 6.0? Would Strawberry even work given the compiler mismatch? I presume Strawberry is compiled with mingw. I would much rather not have to keep my own custom perl build around.
2) If I went the Strawberry route, would something like Inline::C work in the embedded application? You'd have VC++ 6.0 code calling mingw compiled Strawberry in turn calling user mingw compiled code. Inline::C would be an awesome capability for what I'm trying to achieve with the embedded perl interpreter.
Given the uncertainty involved, I would recommend compiling Perl using MSVC instead of experimenting with Strawberry Perl for this application. There are instructions in perlwin32 and a related discussion on Perl Monks to guide you.
As a former release manager for Strawberry Perl, I can tell you it's not terribly difficult to do if you're comfortable with a compiler already.
-- xdg
Activestate perl is compiled with VC++ 6.0. It can use VC++ 6.0 or MinGW to compile modules since they link to the same C runtime library, msvcrt.dll. It would be preferable to use MinGW because VC++ 6.0 is neither free nor readily available (unless you can be sure that it is installed on the target machine.) You can PPM install Mingw now, and compile modules from CPAN. A large number of modules compile without trouble. You may have to configure CPAN with:
o conf yaml_module '' (Two single quotes, nothing between)
o conf commit
Inline::C works.