Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Monday September 29, 2008
04:36 AM

Strawberry Perl October Request for Features

[ #37565 ]

Strawberry Perl is released quarterly and aimed to be available for download on the second Monday of the month (which also means Sunday afternoon in the Hawaii and the Americas)

This quarter, the target release date is October the 13th.

If anyone has any requests for new features to be integrated, please say so now.

Anyone responsible for a module that Strawberry bundles who wants to get new additions into the new release, now is the time to get your new production releases out so I can pick them up.

In the last two days, we've already seen major new releases of Module::Build and ExtUtils::MakeMaker, inching the toolchain closer to complete configure_requires support.

So far this release cycle, I've already flagged the addition of a zero-conf setup for CPANPLUS, so that it works out the box, and rejected any suggestions that I start adding patches to the official Perl release (even to support something as neat as Data::Alias or Module::Signature).

(Having spent a year battling RedHat Perl and it's patched craptasticness, there's no way that I'm patching Perl).

This release will also (hopefully) see the first full beta release of Portable Perl.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I don't know if this is more of a Chocolate thing, but I'd really like a pony.

    And by pony, I mean Expat / XML::Parser. The rationale is:
    - general usefullness (XML)
    - messy to install (external lib)

    I believe the (general * messy) value is quite high, but I may be biased because of needing it the other week.

    • Last time I checked, XML support was the headline feature for the April release.

      So it should be there already... is something not working?

  • Just more work on Portable. Not for USB drives, but just for being able to install Strawberry wherever is appropriate for the environment it's going to run in.

  • I thought that you'd explained how to build Strawberry Perl in a comment here but I can't find it, so I wish that the Strawberry Perl build process was documented somewhere I could find it.
    • Can you see anything useful in Perl::Dist [].

      I'll see what I can do about adding a bit more POD to Perl::Dist::Strawberry [].

    • The short version, however, is this.

      1. Get a Windows machine, with Perl installed somewhere other than C:\strawberry. I have a "bootperl" variant of Strawberry built specifically for that purpose.
      2. Install Perl::Dist
      2. Install Perl::Dist::Strawberry

      Then on the command line, run

      > perldist Strawberry

  • Does that mean one will be able to install Strawberry Perl anywhere?
    There were several people on #win32 recently who wanted to do just that and had to go back to ActivePerl for this.

    Would it be possible to change cpan.bat and other similar files to use relative path for launching perl? That would I think make it possible to install Strawberry Perl along with ActivePerl or other versions of Perl. At least Strawberry perl will behave then nicely.

    Would it be possible to remove the feature (aka fix the pro

    • > Does that mean one will be able to install Strawberry Perl anywhere?

      No, although I'm hoping to have a "real" Portable Edition beta ready.

      > Would it be possible to change cpan.bat and other similar files to use relative path for launching perl?

      Maaaybe, but as I understand things, it's the fault of pl2bat. If that is fixed, Strawberry will just pick up the fix automatically.

      One thing I do plan to look into though is to make the various calls to things like GCC explicit paths rather than relative.


  • Andreas has called a code freeze for to get 1.93 out the door. That's likely to happen before Oct 13, so it should automatically be picked up.

    Bundle::CPAN will also pick up the new Test::Harness.

    -- dagolden

  • It would be very handy to have Strawberry add its build version to the list of local patches the way that ActiveState Perl does so that it's easier to find out which version someone is using when they report a problem or from a CPAN Testers report. E.g. from 'perl -V':

    Characteristics of this binary (from libperl):
      Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV

    • I'll see what I can do...

      Apart from the headline "Strawberry Perl [svn version]" is there any format for (not having the) patches?

      Does any code actually parse it? Or can I just say "No patches"

      • I think it's just advisory. As far as I know, nothing parses it. (But I'd ask on #p5p if you want to make sure.) But I think in Oslo, Tux said it was just whatever text you wanted.

  • I have not checked them or tried to install them and have no tuits to fire up windows, but it would be great to support those.
  • Or at least, please include gdb.
  • I would like to see several add-ons to Strawberry Perl, both probably on the Strawberry web site:

    1) List of modules or external libraries included in the Strawberry Perl releases. I guess it is somewhere listed on Perl::Dist::Strawberry [] but it would be nicer to have a page with list and links to sources and documentations.
    I guess if this info is kept in a yaml file or similar in the PDS itself then it's easy to extract and display.

    2) What can be installed A list of modules that can be installed on Stra