The module solves a real problem and may be useful, but its name completely ruins it.
Great idea, great module.
Don't make your modules depend on some particular logger (as Log::Log4perl). Instead, use Log::Any and let your module users decide which one they want.
I would like to see this module be made part of the Perl core distribution.
This is in response to Michael R. Davis previous comment.
Nowadays there are far more alternatives than the old and unmaintained Net::SSH::Perl for doing SSH from Perl.
Net::SSH2 is a client module implemented on top of the C library libssh2. It is not completely mature yet but the author is very nice and solves reported bugs almost immediately. Also, the API is a bit too C-ish. For file transfer it supports SCP and SFTP, though SFTP support is very rough and not very efficient but Net::SFTP::Foreign can be used on top of it.
Net::OpenSSH is a wrapper around OpenSSH client, with a very powerful and perl-ish API. Only works on Linux/Unix systems (no Windows, no Cygwin, no VMS). It supports SCP and rsync for file transfers and integrates nicely with Net::SFTP::Foreign for SFTP. Net::OpenSSH::Parallel is an extension for using it to run commands in several hosts in parallel. POE::Component::OpenSSH integrates it inside the POE framework.
Net::SSH::Expect, based on Expect, is nice for controlling devices exposing a restricted shell (for instance, routers, bridges, etc.).
Net::SFTP::Foreign is an SFTP client that can use to connect to the remote server the ssh program, plink, Net::OpenSSH or with the Net::SFTP::Foreign::Backend::Net_SSH2 backend Net::SSH2. It's API supports most of the operations you will expect from a modern SFTP client, as recursive operations or globs and is far more robust and much, much faster than Net::SFTP.
This is a response to a previous review by Yarrow:
CPAN Ratings is not a place for reporting bugs. Send an email to the module author or use the CPAN RT system at rt.cpan.org for that.
Regarding your specific issue, the change you are proposing is wrong!
That module is useless, you don't need it!
Implementing C++ STL in Perl is useless because Perl builtin datatypes and functions already offer the same functionality and are much more friendly.
And if something is not natively available from Perl (as linked lists or priority queues), there are much better ways of doing it and more perlish than using the C++ STL API.
I have also suffered Module::Build lack of support for the PREFIX option.
I was trying to install an application on a client server under a home directory. I had configured CPAN to use the correct PREFIX and so, everything was installing smoothly until, one of modules asked for Module::Build and everything become a mesh...
Maybe the directory structures created by ExtUtils::MakeMaker are not the most beautiful ones, but it doesn't harm, so, why to make Module::Build use a different format, one that will stop it from supporting the most useful and common Makefile.PL option, PREFIX???
I have found this module easy to use and quite useful for parsing apache logs.
This module works and is able to parse Apache like config files, but it is too simplistic and lacks some essential functionality like for example, being able to detect and accurately report errors on the configuration file.
Hooks for parsing customization are not available either, and customization of the parser is done in a limited fashion via some predefined attributes that only cover a limited set of cases.
I really would prefer an API reassembling internal Apache config processing (though more perlish) which would allow me fine grained control over the parsing.