Torsten Foertsch wrote:
> I understand the argument why MakeMaker is bad. But it has worked for
> many years now. How do you expect to build a greater user base if it's
> so complicated to do simple things in M::B?
Now, before we drift off into "MakeMaker did it better" land, let me remind
you that MakeMaker has *no* facilities to write README files for you and the
process of hooking into the build or distdir steps is so difficult and
capricious I'm not even sure how to do it, much less do it safely.
> By the way, you haven't answered my initial question. What is
> the "right" way to do that in M::B?
In Module::Build, you override ACTION_code() or ACTION_distdir() or
ACTION_distmeta() to add in whatever you want.
sub ACTION_distmeta {
my $self = shift;
$self->SUPER::ACTION_distmeta(@_);
...do your own README generation...
}
It's that simple. The docs might not always make it look that simple, which
is unfortunate and patchable, but it is that simple.
As for publicizing private methods, I'd rather see customization done like the
above then for Module::Build to try to handle all the TMTOWTDI ways authors
want to get their stuff done. That way lies insanity, maintenance hassles and
bloated, bloated code.
For example, there's a small pile of code in MakeMaker dealing with
automagically committing your files... TO RCS! There's others for making
.shar and uuencoded distributions.
That said, having the create_* parameters take a subroutine reference for
customization seems like a clever idea.
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after eating a junior mint.
-- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
by Tami Farmer
