This is a short set of guidelines for those patching ExtUtils::MakeMaker. Its not an iron-clad set of rules, but just things which make life easier when reading and integrating a patch. Lots of information can be found in makemaker.org. MakerMaker is being maintained until something else can replace it. Bugs will be fixed and compatibility improved, but I would like to avoid new features. If you want to add something to MakeMaker, consider instead working on Module::Build, MakeMaker's heir apparent. Reporting bugs - Often the only information we have for fixing a bug is contained in your report. So... - Please report your bugs via http://rt.cpan.org or by mailing to makemaker@perl.org. RT is preferred. - Please report your bug immediately upon encountering it. Do not wait until you have a patch to fix the bug. Patches are good, but not at the expense of timely bug reports. - Please be as verbose as possible. Include the complete output of your 'make test' or even 'make test TEST_VERBOSE=1' and a copy of the generated Makefile. Err on the side of verbosity. The more data we have to work with, the faster we can diagnose the problem. - If you find an undocumented feature, or if a feature has changed/been added which causes a problem, report it. Do not assume it was done deliberately. Even if it was done deliberately, we still want to hear if it caused problems. - If you're testing MakeMaker against a development version of Perl, please also check it against the latest stable version. This makes it easier to figure out if its MakeMaker or Perl at fault. Patching details - Please use unified diffs. (diff -u) - Patches against the latest development snapshot from makemaker.org are preferred. Patches against the latest CPAN version are ok, too. - Post your patch to makemaker@perl.org. Code formatting - No literal tabs (except where necessary inside Makefile code, obviously). - 4 character indentation. - this_style is prefered instead of studlyCaps. - Private subroutine names (ie. those used only in the same package they're declared in) should start with an underscore (_sekret_method). - Protected subroutines (ie. ones intended to be used by other modules in ExtUtils::*) should be named normally (no leading underscore) but documented as protected (see Documentation below). - Do not use indirect object syntax (ie. new Foo::Bar (@args)) - make variables use dollar signs like Perl scalars. This causes problems when you have to mix them both in a string. If you find yourself backwacking lots of dollar signs because you have one interpolated perl variable, like this: return <_foo_bar Blah blah blah =end private =cut sub _foo_bar { ... - If you're overriding a method, document that its an override and *why* its being overridden. Don't repeat the original documentation.