module-build-general

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

[Ken W. <ke...@ma...>]

[Nadim agreed that I could forward this message to the list, where  
he's now subscribed, so he could get better discussion. -Ken]

Begin forwarded message:
From: Nadim Khemir <na...@kh...>
Date: March 26, 2006 4:33:57 PM CST
To: ke...@ma...
Subject: Module::Build integration with revision control and other  
goodies I need

Hi, remember me and PBS (my module)? We are still using M::B though  
it was
very tough not to go back to a normal Makefile.PL when we started
distributing the module on windows platform. I had a lot of small  
problems,
things that build in cpan other in cpanp and still other with ppm.  
Add to
that some modules that you have to build by hand and you get a real
nightmare. I have added a Makefile.PL using Module::Build::Compat and it
seems to work fine but the 'create_makefile_pl' doesn't. I have  
certainly
done something wrong :)

I'm trying to use M::B more intelligently and I've even read the doc  
twice
(which is what I do every time all goes wrong).Here is what I'm  
trying to put
together this time.

- have a more interactive install. I haven't started yet but I think  
this will
be needed soon. A few examples or links to some modules using this  
would be
great

- I used to have a full cpan miror but I now use CPAN::Mini so I am  
planning
to update my repository directly with CPAN::Mini::Inject and only  
build with
the 'cpan' command. No more ./Build install. or install should call  
'cpan'.

- I'm using svk so I want to be able to create distribution that  
contain the
revision number "0.41.182" everytime I build a distribution (that is
everytime since I need a distribution to inject in CPAN mini so I can  
install
from 'cpan'). Getting the revison and generating the tar.gz is  
trivial when I
am in my project directory but it doesn't work when I install.

# running Build.PL
/usr/bin/perl5.8.8 Build.PL
Creating custom builder _build/lib/PBS/Builder.pm in _build/lib/PBS
path /home/nadim/.cpan/build/PerlBuildSystem-0.41.182 is not a  
checkout path.
Died at Build.PL line 158.
Couldn't run Build.PL:
at /usr/lib/perl5/vendor_perl/5.8.7/Module/Build/Compat.pm line 172.
...

I can think about one solution. when I run 'dist', I make sure svk is  
there
and I create a file that I add to the distribution. At install time,  
I try
with svk and if it fails, I'll fall back on the generated file. This  
is a bit
contrieved. Is there another way to do that?

A Module::Build::SVK would be nice to have.

I'm working on a Module::Build::Inject idea butI'm not sure it's a  
good idea.

Cheers, Nadim.

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

[Nadim K. <na...@kh...>]

So, It has been a few days since this the original mail was send. I'm very 
surprised that no one is interrested in:

- integrating M::B with one's version control tool (version number, 
CHANGES, ...)

- making sure one's project installs properly with 'cpan'

- make the 'install' target work without M::B involvment

- thnking about how to make M::B do more things

Of course if you have all these questions sorted out, a simple URL to where I 
can find these answers would be very welcome.

Cheers, Nadim.

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

[Dr B. <gr...@mo...>]

On Sat, 01 Apr 2006, Nadim Khemir wrote:

> - integrating M::B with one's version control tool (version number, 
> CHANGES, ...)

I have often wanted to ask that question here. Originally, they
were separate in my mind. I was developing using version control
and then bringing in M::B to publish it.

Then I thought about how they should be integrated, and now I am
mostly using module-starter --mb, before doing any development at
all and throwing the whole lot into a repository, even though
that means working 3 or 4 directories deep in lib.

My latest project, however, I am using 'sudo ./Build install'
with every hack, because the development is spread out over my
home directory, and being lax about committing. I haven't been
doing any committing at all.

Which is the opposite of the way I started out.

I would like some guidance too.

-- 
Dr Bean                   Some are born autonomous. Some achieve autonomy.
                          And some have autonomy thrust upon them.
                          --Dr Bean

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

[Nadim K. <na...@kh...>]

On Sunday 02 April 2006 07.27, Dr Bean wrote:
> On Sat, 01 Apr 2006, Nadim Khemir wrote:
> > - integrating M::B with one's version control tool (version number,
> > CHANGES, ...)
>
> I have often wanted to ask that question here. Originally, they
> were separate in my mind. I was developing using version control
> and then bringing in M::B to publish it.
>
> Then I thought about how they should be integrated, and now I am
> mostly using module-starter --mb, before doing any development at
> all and throwing the whole lot into a repository, even though
> that means working 3 or 4 directories deep in lib.
>
> My latest project, however, I am using 'sudo ./Build install'
> with every hack, because the development is spread out over my
> home directory, and being lax about committing. I haven't been
> doing any committing at all.
 May I ask why you aren't committing anything?

A first thing would be to list what we use for version control and what we 
want to achieve. I'll tell my story and hope other will add their.

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

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

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

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

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

this is what I can think about for the revision control/M::B interaction but 
there might be other goodies to find.

Nadim.

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