Yes, I concur with talexb that option 2 is the way to go.

Start a project directory and make subdirs:

lib/
t/
bin/
[download]

/lib/YOUR_DISTRO_NAME/PSjoin.pm
/lib/YOUR_DISTRO_NAME/PS2png.pm
/lib/YOUR_DISTRO_NAME/PStopdf.pm
/lib/YOUR_DISTRO_NAME/Utils/Frobnicate.pm
[download]

use YOUR_DISTRO_NAME::PSjoin;
use YOUR_DISTRO_NAME::Utils::Frobnicate;
[download]

Then when you want to build a distribution in the future your files will be in the proper structure. You don't have to worry about such packaging tools now, but preparing for them is wise.

Hope this helps!

Thank you Alex and 1nickt! You've confirmed what I was hoping was the right way to do it. I'm already part way down the road -- I used the module-starter tool to set up the directory structure (at the moment, for the separate trees, but I'll merge them), and I use github.

If I have multiple .pm files in the bin/ directory, will the normal sequence of perl makefile.PL; make ; etc. catch all the files, or do I need to manually edit the makefile to have it find the multiple .pm files? Thanks again!

If I have multiple .pm files in the bin/ directory

Don't put .pm files in the bin/ directory - put them in the lib/ directory instead. Then yes, they should be found automatically by the build and test process.

To answer your first question, my opinion would be to choose option two -- make them be separate modules, but keep them within one project.

I'm not as much an expert about tools to properly build the distribution, but I've always been a fan of Module::Starter. Create a module skeleton, add your modules in, and you've got version 1.0! Hopefully more experienced module developers will chime in with their comments.

Thanks, that looks really helpful!

You might find some useful tips at Writing Solid CPAN Modules (there's also a long list of references at the end).

Thanks!

I'm in agreement with other Monks here... put each one into its own module file. Do not put all of this within a single module/library.

That said, if there are benefits to separating them out into separate distributions, such as does the one someone wants (PS2png for example) install significantly faster than installing the bundle, is there one out of the many that cause difficulty during install where the others don't, or will the parent ever become extensible where you will add more later?

In those cases (and I've only named three), I'd break it up; each one a separate distribution, then possibly create a top-level distribution that when installed, will bring in all of them together:

Postscript::Objectives;
  - Postscript::PSjoin
  - Postscript::PS2png
  - Postscript::PStopdf
[download]

...for example. That way, your users will be able to install each one individually, or all of them as the top-level bundle distribution.

Drawback to this approach is that there's usually more documentation that has to be created and kept up-to-date, but that's not usually too much of a problem, as you're writing POD for each module anyhow.

Also, typically, that'd mean that you've got several locations for each part of source code (repositories, as it were), so there's a bit more effort on the back-end software management front there. That said, testing can still be all performed for everything in the parent library for all sub-distributions, because it brings in all of them anyhow. This is exactly how I maintain RPi::WiringPi

Update: Forgot to add about one of the benefits of separate distributions... if you ever add a new module to the collective, you need only slight changes to the top-level parent one. Likewise, if they are all separate, fixing a bug in a sub-distribution does not at all affect the efficacy of the top-level one; ie., there's no chance that if you break a sub-dist via an update of any sort, it'll only affect that distribution only; it won't cause a collapse of the whole shebang, even if by mistake and it gets past all of your best efforts of ensuring things don't cascade into a nightmare.