I'm declaring my YAPC::NA 2006 hackathon over. Perl::Dist (Perl::Dist::Builder), Perl::Dist::Vanilla and Perl::Dist::Strawberry are all submitted to CPAN, and checked in to Alias's subversion repository.
Details on Strawberry Perl follow:
Strawberry Perl Alpha 1 is available from vanillaperl.com.
This is an alpha release and is not recommended for production purposes.
The Vanilla Perl Project is an experiment to provide binary Perl distributions for the Microsoft Windows platform that include a bundled compiler. Bundling a compiler provides the ability to install XS CPAN modules directly from CPAN, making the Win32 Perl development more akin to Unix perl development.
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.
Compiler optional? (Score:2)
Re:Compiler optional? (Score:1)
That's a great point. Please add that request to the RT tracker. However, keep in mind that this is just alpha 1 -- there may be some substantial changes along the way, not just "little upgrades".
Generally, if we did the installation right, you won't need every little upgrade as a binary, you can just install new modules from CPAN. (Maybe the module "upgrades" will be released as a "Task" module to simplify that.)
I imagine that new versions of the installer will mostly improve how the installer integ
Re:Compiler optional? (Score:1)
If you do not want a compiler in your Perl distribution, ActiveState makes an excellent Win32 Perl distribution that can meet your needs.
Further, as dagolden mentions, "each little release" only applies during alpha, and I'm afraid we're going with simplicity here.
Once we get to production releases, we expect there to only be one release per Perl release. So it adds 10meg of extra download per 6 months.
I don't see a
Re:Compiler optional? (Score:2)
I am talking about upgrades... You're not suggesting people should upgrade to ActivePerl, are you?
Well, you could have a package with compiler, and the same package but without compiler, for the people who already have the latter.
Re:Compiler optional? (Score:2)
Put a current release tarball (unpacked?) on an rsync server, and let rsync do its magic? Clearly this is only easy if someone has a suitable rsync server already set up.
Re:Compiler optional? (Score:1)
-Ken
Re:Compiler optional? (Score:1)
Re:Compiler optional? (Score:1)
Re:Compiler optional? (Score:1)
Re:Compiler optional? (Score:1)
In the last round, perl stayed the same, some files moved to different directories, a new version of dmake was bundled, IO from the core was upgraded and so on.
When you upgrade, you download again. It's once every 6 months or so, so it's no biggie for 90% of people.
We may well be able to do some sort of no-compiler version for experts, with a big caveat-emptor that we can't predict what will happen with a compiler we haven't preconfi