Personally, I find that any script of sufficient complexity better lives as a module and a "wrapper script" anyway. Most of the time, this process starts once I have to debug the script and have to write tests against specific functionalities of the script. If you find your script is larger than (say) 100 lines, excluding documentation and switch parsing, I think wrapping the script into a module and calling App::BuildPerl::do_it() from the calling script is a sane approach and allows for later utilization/customization of the "application" by another calling script.
External/alien dependencies are hard, but in your case, you could use File::Fetch as a prerequisite, which is what CPANPLUS uses to retrieve files specified via URIs; this is still slated to become core with Perl 5.10. I would specify/optionally require File::Fetch and in case that fails blindly fall back to `wget -o $target "$url"`. You could verify the wget functionality through a test though, or, if you're using Module::Install as your build mechanism, it has requires_external_bin().
Of course, in all cases, it's better to release something than fretting over how to best specify the finer details to make the script work everywhere.
In reply to Re: CPANization of a script for building Perl
by Corion
in thread CPANization of a script for building Perl
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |