develooper Front page | perl.makemaker | Postings from March 2005

What's next for MakeMaker

Michael G Schwern
March 22, 2005 18:26
What's next for MakeMaker
Message ID:
So now that a stable MakeMaker is out, what happens now?  Well, there's
going to be tweaking particularly for getting it to work in the core,
but that's all minor stuff.  What's the big picture?

The big picture is mothballing MakeMaker and only making such changes as
are necessary to fix bugs.  Unfortunately with MakeMaker's lack of API
nearly every change, even internal ones, even just reformatting the Makefile,
can break existing modules.

Read my lips, no new features!

And I intend to be about as successful as Bush I on that one. :)
Unless there's a highly compelling reason, such as "this will help the 
infrastructure of CPAN" or "this will help Module::Build" no new features 
are going into MakeMaker.  I've said this before and I'm tightening down
the screws.

Avoid Makefile formatting changes

As I discovered with the whole pm_to_blib thing, even the formatting of
the Makefile and internal target names are very important.  Lots of modules,
for example, depended on the fact that a pm_to_blib target existed and did
a certain thing.  We can't just say "you violated encapsulation, you lose"
because there really is no good way to do what folks are doing.  Like it or
not, Makefile hacking is how you extend MakeMaker.

So I'm done playing with the Makefile.  Target names are going to stay the
same as much as possible as well as internal method names.

Kicking out auxillary modules

As I've mentioned before, the MakeMaker suite includes a large amount of
modules which are really independent utilities and useful/used by other
modules, particularly Module::Build.

I'd like to kick these out both to reduce the load of maintaining MakeMaker
and to let them have a life of their own.  Most of these modules need some
serious love.

The problem is how to distribute them separately while not introducing a
circular dependency.  Module::Install is the obvious answer but that
currently has cross platform issues.  So before MakeMaker can be slimmed
down, Module::Install needs fixed.

The docs suck

The MakeMaker docs are horrible.  They're disorganized with no real audience
in mind and largely just heave a whole lot of information at the reader.
As a result there's been the impression that writing a module with MakeMaker
involves a lot of voodoo and cargo cultery.

The documentation should be reorganized as follows.

Document MakeMaker from the module *user* perspective.  How do I install a 
module?  This would be the ExtUtils::MakeMaker docs.

Document MakeMaker from the module *author* perspective.  How do I write a
module?  This is what ExtUtils::MakeMaker::Tutorial tries to do.

Document how to extend MakeMaker.  All the idiomatic hacks folks have
built up over the years.

Document all the arguments, commands and targets organized as a reference.


Anyone wanting to do this should just start with a fresh sheet of paper
rather than trying to hammer ExtUtils::MakeMaker into shape.

Test improvements

There are two areas ripe for testing.  

1)  The XS code.  Now that we have a way to detect if there's a compiler
available XS modules can be built as part of the test suite.

2)  Idiomatic hackery.  Make sure we're backwards compatible with common

Modularize PREFIX

Module::Build needs to be able to emulate PREFIX, its the single loudest
complaint people have.  The PREFIX logic is nasty and should not be
duplicated.  It needs to go into a function Module::Build can access,
perhaps into ExtUtils::Install.


I implemented INSTALLBASE to mirror Module::Build's --installbase but
didn't document it, mostly because I couldn't bring myself to look at the
existing docs.

Work on Module::Build

Honestly the upshot of all this is to minimize the amount of work we need
to do on MakeMaker so we can all spend more time firming up Module::Build. Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About