1 "The easy way is always mined.
2 The important things are always simple.
3 The simple things are always hard."
4 -- Some of Murphy's Laws of Combat
6 This is a short set of guidelines for those patching
7 ExtUtils::MakeMaker. Its not an iron-clad set of rules, but just
8 things which make life easier when reading and integrating a patch.
10 Lots of information can be found in makemaker.org.
12 MakerMaker is being maintained until something else can replace it.
13 Bugs will be fixed and compatibility improved, but I would like to
14 avoid new features. If you want to add something to MakeMaker,
15 consider instead working on Module::Build, MakeMaker's heir apparent.
20 - Often the only information we have for fixing a bug is contained in your
23 - Please report your bugs via http://rt.cpan.org or by mailing to
24 makemaker@perl.org. RT is preferred.
26 - Please report your bug immediately upon encountering it. Do not wait
27 until you have a patch to fix the bug. Patches are good, but not at
28 the expense of timely bug reports.
30 - Please be as verbose as possible. Include the complete output of
31 your 'make test' or even 'make test TEST_VERBOSE=1' and a copy of the
32 generated Makefile. Err on the side of verbosity. The more data we
33 have to work with, the faster we can diagnose the problem.
35 - If you find an undocumented feature, or if a feature has changed/been
36 added which causes a problem, report it. Do not assume it was done
37 deliberately. Even if it was done deliberately, we still want to hear
38 if it caused problems.
40 - If you're testing MakeMaker against a development version of Perl,
41 please also check it against the latest stable version. This makes it
42 easier to figure out if its MakeMaker or Perl at fault.
47 - Please use unified diffs. (diff -u)
49 - Patches against the latest development snapshot from makemaker.org are
50 preferred. Patches against the latest CPAN version are ok, too.
52 - Post your patch to makemaker@perl.org.
57 - No literal tabs (except where necessary inside Makefile code, obviously).
59 - 4 character indentation.
61 - this_style is prefered instead of studlyCaps.
63 - Private subroutine names (ie. those used only in the same package
64 they're declared in) should start with an underscore (_sekret_method).
66 - Protected subroutines (ie. ones intended to be used by other modules in
67 ExtUtils::*) should be named normally (no leading underscore) but
68 documented as protected (see Documentation below).
70 - Do not use indirect object syntax (ie. new Foo::Bar (@args))
72 - make variables use dollar signs like Perl scalars. This causes problems
73 when you have to mix them both in a string. If you find yourself
74 backwacking lots of dollar signs because you have one interpolated
75 perl variable, like this:
79 \$(NOECHO)cd $subdir && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
83 or are switching quoting contexts:
87 $(NOECHO)cd }.$subdir.q{ && $(MAKE) -f $(FIRST_MAKEFILE) all $(PASTHRU)
91 consider using sprintf instead.
93 return sprintf <<'EOT', $subdir;
95 $(NOECHO)cd %s && $(MAKE) -f $(FIRST_MAKEFILE) all $(PASTHRU)
100 Refactoring and Cleanup
102 - MakeMaker is a mess. We like patches which clean things up.
105 Backwards Compatibility
107 - MakeMaker must be backwards compatible to 5.5.4 (5.005_04). Avoid any
108 obvious 5.6-isms (threads, warnings.pm, Unicode, our, v1.2.3, attributes
109 open my $fh, lvalue subroutines, qr//, any new core modules, etc...).
111 - MakeMaker should avoid having module dependencies. Avoid using modules
112 which didn't come with 5.5.4 and avoid using features from newer
113 versions. Sometimes this is unavoidable.
116 Cross-Platform Compatibility
118 - With the exception of MacOS Classic, MakeMaker must work on all
119 architectures Perl works on (see perlport.pod). This means all Unixen
120 (including Cygwin and MacOS X), Windows (including Win9x and DOS), and VMS.
122 - Use the available macros rather than shell commands $(MV), $(CP),
125 - MakeMaker must work on many makes. GNU, BSD, Solaris, nmake, dmake, MMS
126 and MMK to name the most common. Keep your make code as simple as
129 - Avoid special make variables (even $@).
131 - Format targets as "target : dependency", the spacing is important.
133 - Use $(NOECHO) instead of @.
135 - Use - to tell make to ignore the exit code of a command. (Unfortunately,
136 some make variants don't honor an $(IGNORE) macro).
138 - Always put a space between $(NOECHO) and the command.
140 - Always put a space between - (ignore) and the command.
142 - Always put $(NOECHO) and - together, no space between them.
149 - Often when you patch ExtUtils::MM_Unix, similar patches must be done
150 to the other MM_* modules. If you can, please do this extra work
151 otherwise I have to. If you can't, that's ok. We can help.
153 - If possible, please test your patch on two Very Different architectures.
154 Unix, Windows and VMS being Very Different. Note: Cygwin and OS X are
155 Unixen for our purposes.
157 - If nothing else, at least try it on two different Unixen or Windows
158 machines (ie. Linux and IRIX or WinNT and Win95).
160 - HP's TestDrive (www.testdrive.compaq.com) and SourceForge's
161 compile farm (www.sourceforge.net) are good sources of testing
162 machines of many different architectures and platforms. Accounts are
165 - If you find yourself writing "do_this if $^O eq 'That'" (ie. checks on
166 the OS type) perhaps your code belongs in one of the non-Unix MM_*
167 modules (ie. MM_Win32, MM_VMS, etc...). If one does not exist, consider
168 creating one. Its ok to have an MM_* module with only one method.
170 - Some shells have very small buffers. This means command lines must
171 be as small as possible. If your command is just too long, consider
172 making it an ExtUtils::Command::MM function. If your command might
173 receive many arguments (such as pod2man or pm_to_blib) consider
174 using split_command() to split it into several, shorter calls.
176 - Most shells quote differently. If you need to put a perl one-liner
177 in the Makefile, please use oneliner() to generate it.
182 - Tests would be nice, but I'm not going to pretend testing MakeMaker
183 is easy. If nothing else, let us know how you tested your patch by
189 - Documentation would be nice.
191 - If the new feature/method is private, please document it with POD
192 wrapped in "=begin/end private" tags. That way it will be documented,
193 but won't be displayed (future versions of perldoc may have options
211 - If you're overriding a method, document that its an override and
212 *why* its being overridden. Don't repeat the original documentation.