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.
Re:Looking at this another way...
Ovid on 2006-09-14T12:59:18
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 => {},
build_requires => {
'Test::More' => 0.6,
},
add_to_cleanup => ['aliased-*'],
create_makefile_pl => 'traditional',
);
$builder->create_build_script();When I build, it automatically creates this:
# Note: this file was auto-generated by Module::Build::Compat version 0.03
use ExtUtils::MakeMaker;
WriteMakefile
(
'PL_FILES' => {},
'INSTALLDIRS' => 'site',
'NAME' => 'aliased',
'EXE_FILES' => [],
'VERSION_FROM' => 'lib/aliased.pm',
'PREREQ_PM' => {
'Test::More' => '0.6'
}
);I try hard to make sure that my modules are easy to install, regardless of how you want to install them.
Re:Looking at this another way...
jonasbn on 2006-09-14T15:58:23
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.
Re:Where to direct your inquiry
runrig on 2006-09-14T16:53:19
I believe it would be here when the site decides to work again.Re:Where to direct your inquiry
runrig on 2006-09-14T17:56:05
Ignore link above, site works now, and it's in this list.
Re:Strawberry Perl
Aristotle on 2006-09-15T00:43:38
Why so?
Re:Strawberry Perl
sigzero on 2006-09-15T15:35:27
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.
Re:Strawberry Perl
Ovid on 2006-09-15T16:06:22
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.
Re:Strawberry Perl
sigzero on 2006-09-15T16:18:13
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.
Re:Strawberry Perl
Ovid on 2006-09-15T17:47:12
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 modules through their build system could be quite a drain. That being said, I think they chose the wrong model. Had they simply bundled ActivePerl with its own compiler and make, I think folks would have been much happier with them, particularly since PPM is easier for newer users than cpan or cpanp.
Re:Strawberry Perl
sigzero on 2006-09-15T18:16:35
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.
Re:Strawberry Perl
sigzero on 2006-09-20T01:26:21
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.
