dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

I am almost ready to release the new version of PDF::Template (Yay!). One sticking point has been my lack of knowledge of the module build process, from the developer's side.

My major concern is the Unicode support. If you're running pre-5.8 and you want to use non-English, I have to require you have Unicode::String installed. But, if you either won't be using non-English or you have 5.8+, I don't want to force you to install it. Also, I'd like to be able to change the code that's actually installed so that you aren't burdened with the overhead of a feature you don't want to use. (Right now, Unicode::String is required, and I don't like that.)

Additionally, in the next release, I will be supporting both PDFLib and PDF::API2 as the rendering options. (Right now, only PDFLib is supported.) How do I work within the CPAN framework so that "follow" works correctly? (I'm also going to want to do a similar thing with XML parsers. Right now, I use XML::Parser, but I'd like to be able to support SAX parsers ...)

Also, is there a clean way of using warnings if 5.6+ and -w if not? There are a few places I do something like no warnings 'once';, but I don't want to require 5.6+ just to use my module. I wouldn't mind optionally converting those to local $^W = 0;, but I'd prefer to keep the interface to warnings, if supported. (Or, am I just being a pansy?)

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Varying module build options
by mirod (Canon) on Nov 18, 2003 at 15:54 UTC

    Although it might not be perfect, here is what I do for XML::Twig. Note that none of the modules I check are needed, so just display messages if I don't find them, but I would think that dying should stop the installation process.

    The Makefile.PL file includes a line that runs this code:

    #!/bin/perl -w

# $Id: check_optional_modules,v 1.2 2003/09/24 13:35:07 mrodrigu Exp $

use strict;

exit if( $] >= 5.008); # Encode is there, so is Scalar::Util

if( $] >=  5.0060)
{ unless( eval 'require Scalar::Util' or eval 'require WeakRef' )
      { warn "Neither Scalar::Util  nor WeakRef is  installed. ",
             "Installing  one of these modules  would  improve ",
             "XML::Twig memory management and eliminate memory ",
             "leaks when re-using twigs.\n";
      }
    else
      { warn "weaken is available\n"; }
  }

unless( eval 'require Text::Iconv')
  { my $version= `iconv -V` || '';
    if($version)
      { warn "The iconv library was found on your system ",
             "but the Text::Iconv module is not installed. ",
             "Installing Text::Iconv would make character ",
             "encoding translations fast and efficient.\n";
      }
    else
      { warn "Did not find iconv\n"; }
  }
else
  { warn "Text::Iconv is installed\n"; }

    [download]

    I also run a script that creates the real .pm file from the file I maintain. Amongst other things, this script turns qr// constructs into plain strings for (very!) old versions of Perl. You could probably use such a trick to turn no warnings 'once'; into local $^W = 0;.

[reply]
[d/l]
      I also run a script that creates the real .pm file from the file I maintain.

      I use a similar approach with forks, but that script is integrated into the build process. The XS file is needed for 5.6.X is different from the one that is needed with 5.8.X. When you execute Makefile.PL, it creates the version of the XS file that is needed for that version of Perl. I assume a similar approach could be used for your Perl module.

      Liz

[reply]
Re: Varying module build options
by ptkdb (Monk) on Nov 18, 2003 at 15:23 UTC
    Alot can be accomplished by testing the system configuration while the Makefile.PL is running. You can check their versions there. Also, the 'use Config' module tells you quite a a bit about the installtion. The fields PERL_REVISION, PERL_VERSION, PERL_SUBVERSION will give you a precise version of perl. $ENV{LANG} might give you a hint as to whether it's a non-English locale.
[reply]
      Do you have some favorite examples of these? Are there any books/docs that describe more fo the Makefile.PL options? I'm really in the dark here as to even what's possible ...

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      ... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]
        Look at the Makefile.PL for PerlTk. There are quite a few things going on in there that are NOT documented in ExtUtils::MakeMaker.
[reply]

Back to Seekers of Perl Wisdom