On Sat, 16 Feb 2002, Sean M. Burke wrote:
> I've written a program called makepmdist (which I'm planning to put in
> CPAN, once I get a bit of feedback on it) that simplifies the task of
> making a dist of a single module.
Funky. Currently I'm typing many many commands to make a distribution.
Please take everything I say here as constructive crisism. Also please
feel free to say "That's too much effort" or "This isn't in the remit of
the script"
> It's not meant to handle every kind of module in CPAN. It's just meant
> to the common case of a pure-Perl modules that is the only module in its
> dist. (For example, that describes about half of the dists in my CPAN
> directory.)
I'd agree with just having pure perl modules, as it greatly simplifies
everything.
Currently this fails if the package declaration is on the first line of
the module.
This also fails if the module isn't a top level named module. For
example, I wrote a module called "Bar::Foo" with the filename "Foo.pm" (as
I would normally do.) makepmdist fails with the error "Can't find
"package Foo;" line in Foo.pm". Am I using this wrong? (I tried
Bar/Foo.pm and Bar::Foo.pm too)
Suggestion: Quite a lot of things I do use more than one module too. How
about simplifying it to the named module and any subclasses in the current
directory of that module. i.e. for Foo.pm, it check for a directory "Foo"
that contains further modules. Or something like that. Maybe this needs
more thought.
> Basically, you say "makepmdist Foo.pm" and it does some very minimal
> sanity-checking on Foo.pm,
I like the sanity checking aspect. Is it possible to add a few other
things to it?
You say in the documentation "nor does it check the validity of your Pod
syntax -- you should really have done that already by using
C<podchecker>". It'd be nice if the script did that for me automatically
- as it's meant to be a one line command I type in to make the
distribution then not having to do a second command to check the pod would
be good. I always forget to do that.
Other checks would be nice too, how about something that loads the module
into memory and then checks what modules are in INC and winges at you
when they're not listed in the dependencies? This wouldn't get all cases
(i.e. things brought in at other than BEGIN time, but it would help.
Something to make sure I've changed the version number? I always forget
to do that (um, not sure how this would work...maybe it could add a
comment to the original source to say that it's already seen a version)
> then makes a temp directory in which it copies
> Foo.pm, makes a Makefile.PL, a README, a MANIFEST, and a t/test.t. Details
> of the contents of the Makefile.PL and the t/test.t are controlled by
> optional =for blocks in the Foo.pm file.
It'd be nice if this could be compatible with Test::Inline. I can't
stand =for blocks for my tests, as I like to leave whitespace between
them. I use =begin testing and =end testing.
I'd also have it create a manditory 00basic.t test that just checks the
code compiles okay (i.e. it does the equivilant of Test::More's "use_ok"
function on the module)
> (It also does some nice things like make sure that the Foo.pm that gets
> disted is in Unix newline format and has a $VERSION; and it warns about
> any ridiculously long lines in the file.)
Nice.
> Then it makes test, dist, clean, moves the resulting .tar.gz up and out,
> and kills the temp dir -- unless there was a fatal error along the way,
> at which point it would just abort and let you ponder the temp dir's
> contents.
Handy. This is good and what I'd expect to happen.
> I wrote this someone at YAPC about two years ago said it'd be nice if
> disting a module were a one-step process; and I liked that idea. Well, it
> almost is one-step now, if the module is simple enough (i.e., no XS, and is
> the only module in the dist), and if you don't count the part about
> actually submitting it to PAUSE, which would bring this to an aching TWO
> steps.
I wouldn't want automatic submission to PAUSE. Some of my stuff is in
it's sixth version and still not fix for human consumption, only that of
my fellow developers.
Hope this has been helpful.
Later.
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
