Stories
Slash Boxes
Comments
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 ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday September 14, 2006
03:54 AM

Encourage ActiveState to do the Right Thing

[ #30991 ]

I've noticed that ActiveState's PPM does not provide TAPx::Parser on all platforms because Module::Build is not building on all platforms (it a dependency chain hell). I've now sent ActiveState's support email address the following:

I'm not sure where to direct this inquiry. I've noticed on http://ppm.activestate.com/BuildStatus/5.8-T.html that my TAPx::Parser module is failing to build on some installs because Module::Build does not build cleanly on all of your platforms. However, most of my modules, including TAPx::Parser, also include a compatible ExtUtils::MakeMaker script (Build.PL versus Makefile.PL). Would it be possible to adjust your systems to fall back to the Makefile.PL, if present, if the module fails to build with the Build.PL? By doing this, you would be able to offer many more modules via PPM.

On the flip side, we could simply enourage more people to use Strawberry Perl.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Encourage ActiveState to do the Right Thing 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Maybe this could encourage you to use ExtUtils::MakeMaker instead?

    • I use both. Here's a typical Build.PL file of mine:

      #!/usr/bin/perl -w

      use strict;
      use Module::Build;

      my $builder = Module::Build->new(
          module_name       => 'aliased',
          license           => 'perl',
          dist_author       => 'Curtis "Ovid" Poe <moc.oohay@eop_divo_sitruc>',
          dist_version_from => 'lib/aliased.pm',
          requires          => {

    • A word on Module::Build

      I actually prefer Module::Build over ExtUtils::MakeMaker simply due to it's extensibility, Module::Install however seems to be very popular these days - I have no experiences with this module however.

      I use Module::Build extensively for non-CPAN projects aswell and this has proven quite resourceful, adding new actions for building databases, adding users etc.

      In my opinion Module::Build is a good module, it scratches my itch.
  • They have a mailing list specifically for the packaging system. I would provide a link, but they seem to be having technical difficulties with their site at the moment.
  • Well you could...but it would be hard to convince me to replace a "stable" ActiveState install with it.

      • From the wiki:

        Strawberry Perl is currently an alpha release and is not recommended for production purposes.

        My PHB would not like me doing that.

        • And your PHP would be right. However, when Strawberry Perl is ready for production, I can't imagine a reason in the world why anyone would want to stick with ActiveState.

          • I don't understand the PHP comment. I *hate* PHP. However, ActiveState works for our shop (Windows) and they have been very helpful when I have posed questions to them.

            Once Strawberry hits a couple beta levels then I will try it. I *do* like the premise behind it.

            • I meant "PHB". Whoops :)

              The nice thing about Strawberry Perl is that it comes bundled with its own compiler and make. As a result, you can use cpan and cpanp just like any other Perl installation. You're not dependent on ActiveState providing you a PPM or hunting around for a PPM from somewhere else.

              That's not to say I have anything against ActiveState. They're a company, they need to earn money and they need to figure out the best allocation of their resources and shepherding a bunch of CPAN module

              • Ohhhh! PHB! I hate those too. : )

                I will move to Strawberry Perl just because:

                • It will give me more control
                • I will be able to contribute back

                Those 2 reasons are good enough for me any day.

              • One thing I don't like is it sometimes takes them a long time to get secondary modules up-to-date. I just looked at Object::InsideOut and it is at 2.01 but I can only get 1.45 from PPM. I know they do their thing because of the binary support and corporate assurance but I can make those decisions.

                SP just needs to get beta or something for me to try it at work is all.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.