home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PC World 2005 June
/
PCWorld_2005-06_cd.bin
/
software
/
vyzkuste
/
firewally
/
firewally.exe
/
framework-2.3.exe
/
PATCHING
< prev
next >
Wrap
Text File
|
2003-11-07
|
6KB
|
181 lines
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 <<'EOT'
subdirs ::
\$(NOECHO)cd $subdir && \$(MAKE) -f \$(FIRST_MAKEFILE) all \$(PASTHRU)
EOT
or are switching quoting contexts:
return <<q{
subdirs ::
$(NOECHO)cd }.$subdir.q{ && $(MAKE) -f $(FIRST_MAKEFILE) all $(PASTHRU)
};
consider using sprintf instead.
return sprintf <<'EOT', $subdir;
subdirs ::
$(NOECHO)cd %s && $(MAKE) -f $(FIRST_MAKEFILE) all $(PASTHRU)
EOT
Refactoring and Cleanup
- MakeMaker is a mess. We like patches which clean things up.
Backwards Compatibility
- MakeMaker must be backwards compatible to 5.5.3 (5.005_03). Avoid any
obvious 5.6-isms (threads, warnings.pm, Unicode, our, v1.2.3, attributes
open my $fh, lvalue subroutines, any new core modules, etc...).
- MakeMaker should avoid having module dependencies. Avoid using modules
which didn't come with 5.5.3 and avoid using features from newer
versions. Sometimes this is unavoidable.
Cross-Platform Compatibility
- MakeMaker must work on all architectures Perl works on (see perlport.pod)
and with many different versions of make. This means all Unixen
(including Cygwin and MacOS X), Windows (including DOS), MacOS Classic
and VMS.
- Often when you patch ExtUtils::MM_Unix, similar patches must be done
to the other MM_* modules. If you can, please do this extra work
otherwise I have to. If you can't, that's ok. We can help.
- If possible, please test your patch on two Very Different architectures.
Unix, Windows, MacOS Classic and VMS being Very Different. Note: Cygwin
and OS X are Unixen for our purposes.
- If nothing else, at least try it on two different Unixen or Windows
machines (ie. Linux and IRIX or WinNT and Win95).
- HP's TestDrive (www.testdrive.compaq.com) and SourceForge's
compile farm (www.sourceforge.net) are good sources of testing
machines of many different architectures and platforms. Accounts are
free.
- If you find yourself writing "do_this if $^O eq 'That'" (ie. checks on
the OS type) perhaps your code belongs in one of the non-Unix MM_*
modules (ie. MM_Win32, MM_VMS, etc...). If one does not exist, consider
creating one. Its ok to have an MM_* module with only one method.
- Some shells have very small buffers. This means command lines must
be as small as possible. If your command is just too long, consider
making it an ExtUtils::Command::MM function. If your command might
receive many arguments (such as pod2man or pm_to_blib) consider
using split_command() to split it into several, shorter calls.
- Most shells quote differently. If you need to put a perl one-liner
in the Makefile, please use oneliner() to generate it.
Tests
- Tests would be nice, but I'm not going to pretend testing MakeMaker
is easy. If nothing else, let us know how you tested your patch by
hand.
Documentation
- Documentation would be nice.
- If the new feature/method is private, please document it with POD
wrapped in "=begin/end private" tags. That way it will be documented,
but won't be displayed (future versions of perldoc may have options
to display).
=begin private
=item _foo_bar
$mm->_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.