Adam Kennedy wrote:
> Firstly, there's gunna be some issues modifying modules at release time.
> Primarily, you haven't provided any way to SAVE those changes, since
> 90%+ of modules are built out of version control.
The changes it makes aren't things I want to save anyway. For example,
the repository copy of a module has:
=head1 VERSION
This section is filled in by C<Build distdir>.
instead of a normal VERSION section.
> This means a gotcha
> where the version labelled as 1.00 in the repository is not necessarily
> the same thing as what is in the tarball, because someone forgot to commit.
I don't see how my enhancements make this worse. You can already Build
dist without checking in first.
> Option 1: Custom Build.PL
I'd already rejected that.
> Option 3: A CPAN-released seperate subclass.
>
> You put use Module::Install::Chris in your Build.PL, and it's just gunna
> blow up, because nobody has that module and you have no way of ensuring
> that they do.
No, that's what eval is for. The whole point of this is that people who
merely install the module don't need Module::Build::Dist and shouldn't
have to care that it exists. I'm thinking of something like this:
use Module::Build;
eval 'use Module::Build::Dist;';
my $class = ($@ ? Module::Build->subclass(code => q{
sub ACTION_distdir {
print "You might want to install Module::Build::Dist\n";
(shift @_)->SUPER::ACTION_distdir(@_);
} })
: 'Module::Build::Dist'); # if we found it
my $builder = $class->new(...);
$builder->create_build_script();
If I needed a custom subclass for other module-specific reasons, I'd put
similar code in there.
> Option 4: A separate release tool.
>
> Brian Foy released his as Module::Release.
I'd overlooked that. I'll have to look into it.
--
Chris Madsen [EMAIL PROTECTED]
-------------------- http://www.cjmweb.net --------------------
