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. http://www.makemaker.org/wiki/index.cgi?ModulesForSale 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. A FAQ. 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 hackery. 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. Document INSTALLBASE ******************** 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.
