[Phil]

Yes, the title is a bit of an oxymoron, but I got your attention, didn't I?

Anyway, I'm in discussion with a bug reporter about using the Graphics::TIFF library to support TIFF image handling. Now, not that many users of a PDF::Builder-based program are going to be handling TIFFs (especially Group 3 and Group 4 Fax), so I hesitate to include a seldom-used library in the build prerequisites. In the CPAN world, what is the protocol and custom in requiring seldom-used libraries in a build? It appears that I will sometimes get an error during the compilation stage of running a program, if I put "use Graphics::TIFF;" in a .pm file, and don't have it installed. Other times (depending on where the "use" is), I don't, so that would suggest that I don't have to list all used modules in the build process. Is this practice considered clean or sloppy? If Graphics::TIFF isn't installed, I want to handle any "not found" error with a message "You need to install the Graphics::TIFF package if you want to use TIFF functionality.", but only show that message from within the TIFF module(s) that need it.

Font::TTF is a current requirement that applies only to TrueType font handling, so it too might be a candidate for being made optional. In the future there might be a number of BarCode-related libraries that should not be made mandatory. Or am I just overthinking this, and no one cares if a package like PDF::Builder installs modules that they'll never use? What is considered best practice?

Add: P.S. Obviously, if a library such as Graphics::TIFF is optional, it can not be in the standard "t" tests for installation. For the benefit of developers, "t" tests using this library could be put somewhere else (perhaps as t/optional/tiff.t?), so long as the standard install tests don't try to run them.

[sciurius]

It mostly depends on the packager. For example, Fedora packaging guidelines say that you should include optional prerequisites. Debian says the opposite.

The CPAN::Meta::Spec (used by CPAN) has advisory elements ('recommends') but this is barely supported yet.

In general, include what would be a good starting point for most purposes. For PDF::Builder, this means including Font::TTF since it will almost always be needed.

[Phil]

Just a further note that Graphics::TIFF currently can not be installed on all Perl installations, as it requires libtiff.a (it's just a thin wrapper around that archive). libtiff.a is not always available. Therefore, I cannot formally prereq Graphics::TIFF, as there will be some cases where it simply can't be installed, and thus PDF::Builder would not be installable!

I am trying to work with the Graphics::TIFF author to see if somehow either libtiff.a could always be built (if it's not supplied with the OS or by Perl), or a Graphics::TIFF "fat client" could be built that links in the compiled libtiff.a's C source code. If not, it will simply be a soft fail on any system that doesn't have Graphics::TIFF installed [yet/ever] if certain TIFF functions are used.

[Phil]

What I ended up doing (see https://www.catskilltech.com/forum/pdf-builder-general-discussions/how-to-handle-tiff/) was not including Graphics::TIFF in the prerequisites list, so PDF::Builder will install whether or not Graphics::TIFF is installed (and will not try installing it). Two of the library routines that are modified to use Graphics::TIFF get _GT suffixed to their names, while still preserving the old versions (net change: two new modules added). Builder.pm decides which one can be used, by a combination of testing whether Graphics::TIFF is installed, and if it is, whether the user has requested that it not be used. There is a known limitation in Graphics::TIFF that a file handle cannot be passed in, unlike the old modules, where either a file name or a handle may be given. Thus, in some cases, a user may need to use the old code (however, it is still broken in many places!).  Finally, there is a method provided to test whether Graphics::TIFF is installed (and in use), and the user can skip certain code if it is (or isn't). The t-tests for TIFF have to skip a couple tests that absolutely require Graphics::TIFF (also, there are a couple tests that have to use the old modules).

Eventually, if and when Graphics::TIFF becomes available (or buildable) on all Perl installations, we can just prereq Graphics::TIFF and forget about the old modules. The "no file handles" limitation may just become a hard incompatibility with old code.

[Phil]

Some modules (TIFF_GT.pm and the new PNG_IPL.pm) make use of optional libraries. Both bit me during CPAN tests by requiring those libraries (uninstalled on most test systems) during t/00-all-usable.t. I have added manual reminders to Makefile.PL and my build routine (PDFbuild.pl) to add to the exclusion list in 00-all-usable.t if a new optional library is used. Perhaps I should consider, instead, testing for those particular libraries (as I do within TIFF and PNG processing) and only calling the _GT and _IPL version test loads if the libraries are installed. Unfortunately, this is still a manual step (remembering to update 00-all-usable.t) so I'm not sure how much of an improvement it would be. At least, those two modules would not be automatic "pass" results, and could fail for other reasons.