MakeMaker is the standard utility for generating makefiles to install Perl modules. If you plan on creating a Perl module distribution for CPAN, it's a sure thing that you're gonna have to do battle with this beast at some point.
I'll try to keep this short:
1) The documentation isn't all that great.
Notice, it doesn't even say exactly what the behavior of the default makefile will be, just that, "The generated Makefile enables the user of the extension to invoke..." Yeah, and what will that do? Will it move everything in ./lib to the Perl site/lib directory? Will it leave everything else alone? Will it try execute every *.pl script that comes with the distribution or move them to the /usr/bin directory? The docs don't say, at least not in a clear, obvious way. Instead, you have to go searching through the documentation for each and every possible option for WriteMakefile() to find out.
2) It's useless for anything else.
MakeMaker can't be used to create general-purpose makefiles for installing general-purpose Perl applications. Yes, I know what you're going to say: "MakeMaker is for installing modules, not applications!" That's true, but it could have easily been extended to do both; if we could just tell MakeMaker what to mess with and what not to mess with and where to put what it messes with it would be infinitely more useful. You can sort of do this now by creating your own MakeMaker class and overriding "make install," but thisï¿½like a makefile itselfï¿½is a royal pain in the ass.
There's certainly something to be said for doing one thing and doing it well, but notice that if h2xs did just that, then MakeMaker wouldn't be extolling its virtues.
3) It makes makefiles in the first place.
I know I'm not making any friends here, but why the heck are we even using makefiles in the first place? Especially makefiles littered with Perl one-liners and shell commands? Isn't this what *Perl* is for?
I honestly HATE makefiles. The syntax is awful, they're not portable (a makefile written for MacOS probably won't work with GNU Make on Linux, for example), whitespace matters (and yet GNU make only accepts linefeeds as line endings), and they're so damn complicated that you find yourself just hoping with all your heart that they work, because if they don't, well, you're probably screwed. I'd be willing to wager that the vast majority of makefiles are machine-generated rather than hand-edited by a thoughtful human developer either as result of or in response to their ever-increasing complexity.
All and all, this was interesting but very bad idea. It's time for MakeMaker to be retired. We now have Module::Build, a lovely pure-Perl utility for installing modules. Here's what current maintainers of MakeMaker say about Module::Build:
"Module::Build is the official heir apparent to MakeMaker and we encourage people to work on M::B rather than spending time improving MakeMaker." - ExtUtils::MakeMaker::FAQ.
Stay away from MakeMaker unless you absolutely have to use it, which, unfortunately, you probably do.
As far as XML generation goes, XML::Writer is probably as easy, simple, and efficient as it gets. While this most recent version incorporates no new functionality, the prior version added several neat features: the DATA_MODE, DATA_INDENT, and NEWLINES parameters, whichï¿½when combinedï¿½effectively allow you to control the style of the markup.
The biggest drawback of this module still remains, though. XML::Writer requiresï¿½no matter whatï¿½an IO::Handle object for a file handle to be used to output XML to. This makes dynamically outputting XML to a scalar, something that should be relatively easy, surprisingly difficult, requiring some additional magic from IO::String to treat a scalar as though it were a file handle. While this is no longer an issue for users of Perl 5.8, if you're still using a prior version of Perl or writing a module for CPAN, this remains a very annoying problem.
This is functionality that probably could have easily been added to the module.
I also think the requirement of IO::Handle/IO::File objects in place of straight file handle names or file handle references could have been removed by some typeglobbing and symbol table work on the author's partï¿½IO::Handle is used for author's convenience, not ours.
XML::Parser was the first decent Perl interface to XML. It links to James Clark's Expat, the original XML-parsing C library, which handles most of the heavy lifting.
XML::Parser uses the event-driven parsing model as opposed to the tree-based model: rather than parsing XML into a big, treelike data structure, with XML::Parser you define event handlers for certain events (like the start of the document, encountering the start of a tag, encountering an XML comment) that get called as those particular events occur.
XML::Parser works; it's quite mature, as is the underlying C library. XML::Parser is very, very fast. XML::Parser is very well documented.
The only gripes I have with XML::Parser are over its API. It appears that a naming convention is non-existant. If there is indeed a naming convention, then it's an extremely confusing one. For example, some methods are named with the first letter of every subsequent word uppercased, like setHandlers(). Most have an underscore separating each world, a la perlstyle, like current_element(), eq_name(), new_ns_prefixes(), or default_current(). Still some have nothing separating words, like parsestring() or parsefile(). The named parameter syntax suffers from similar problems. Maybe this is attributable to the fact that there were two different authors (three if you count Clark himself) or maybe there really is some big, complicated naming convention that makes perfect sense to the current maintainer, but either way I find all of this extremely unintuitive.
As mentioned by another reviewer, the SAX modules are another, more standardized optionï¿½one with an API devoid of any of the problems enumerated above. XML::Parser still has much wider distribution, though, and there are many SAX modules to choose from (XML::SAX::PurePerl, XML::Parser::PerlSAX, XML::LibXML::SAX, for example), which is either a very good thing or a very bad thing depending on your preference.
The inertia now in the XML community is definately away from specialized tools like Expat and towards more standardized APIs like SAX.