Re: [Module::Build] Fwd: Module::Build integration with revision control and other goodies I need

[John P. <jpe...@ro...>]

Nadim Khemir wrote:
> I use SVK (though it has seriously upset me lately) and here are the things 
> I'd like to do (no particular order):
> 
> -when I do a 'dist', I want a CHANGES to be generated automatically

See most any of my modules on CPAN for code like this:

use Module::Build;

my $class = Module::Build->subclass
(
    class => 'Your::Module::Name::Builder',
    code => q{
    sub ACTION_dist{
        my $self = shift;
        $self->do_system('svk log -x | gnuify-changelog.pl > Changes');
        $self->SUPER::ACTION_dist();
        };
    },
);

my $m = $class->new
    ( module_name     => 'Your::Module::Name',
      license         => 'perl',
      requires        => {
          'Module::Build' => 0.2611,
      },
...blah...blah...blah...
     );

$m->create_build_script;

> - I want the version to be major.minor.revision and I want that to be 
> automatic of course

Not currently easy, either with SVK or SVN; I'm hoping to get some time to work
on inherited properties, which will make this much easier.  The problem is two-fold:

A) Need a way to determine, automatically, which sub-version to increment based
on some sort of external criteria;

B) Need to populate all of the correct files with the new $VERSION; it is
sometimes impossible to have all sub-modules share the same $VERSION as the
master module (because during testing, the submodule may inherit the wrong
$VERSION, e.g. the installed master module rather than the testing).

This is something I intend to add to Module::Release at some point (see below).
 I have a preliminary cut at version::Math which will make generating the
appropriate $VERSION much easier.  I forsee something like

	$ release --minor

which would bump the minor and set the revision to 0.  'release' should be smart
enough that if you don't pass any parameter, and the associated $VERSION tag
already exists to bump the revision instead.  This behavior should probably be
set in .releaserc.

> - The MANIFEST could also be automatically extracted from what I check in.

You can use Module::Release (and the commandline 'release' script) to automate
this (or at the very least to see which files didn't get added).  'Build
distclean' will also warn about which files exist but aren't in MANIFEST.  I
don't personally want MANIFEST built automatically from checkins, because in
more than one occasion, I have files in the repository that are used to automate
certain testing setup, but should not be distributed with the public release.

> - The dependencies  my modules have shouldn't have to be explicitely written 
> but extracted

See Module::Info for a way to extract this information; creating dependencies
automatically is left as an exercise for the programmer. ;-)

> - commit shouldn't (must not?) be allowed if testing fails.

'release' will not upload the module to CPAN or SourceForge unless both 'test'
and 'disttest' pass.

As far as I am concerned, none of this functionality belongs in Module::Build,
which works in a very different problem space.  I see SVK and Module::Build
being tangential to each other, and would rather see Module::Release improved to
automate these tasks.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747