httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James G Smith <JGSm...@TAMU.Edu>
Subject [RFC] Apache::Build
Date Wed, 16 Jul 2003 20:45:34 GMT
I've been moving several of my Perl modules from MakeMaker to
Module::Build.  I'm not seeing support for Module::Build in the
Apache::Test suite, so I thought I'd take a stab at subclassing
Module::Build to provide support for it.

I couldn't access the searchable archives for this list (get sent
back to, but I did look through this month's
archive and didn't see anything obvious along this line.

Several questions before I jump even more head-long into this.

(1) Is Apache::Build a sensible, everyday name?  Should it perhaps
reside instead under Module::Build or Apache::Test?  I have no
problem with this module being its own distribution on CPAN.  I also
have no problem contributing it to an existing project.

(2) How DWIMmy should it be?  I like the following for my Build.PL
(as a goal):

 use Apache::Build;
 my $build = Apache::Build->new (
     module_name => 'Apache::Foo',
     license => 'perl',
     requires => {
         'perl'           => '5.6.1',
         'Some::Module'   => '1.23',
         'Other::Module'  => '>= 1.2, != 1.5, < 2.0',

It should just work :)  This would also make any t/*.PL files into
t/* files.

(3) Support for multiple versions of Apache/mod_perl.

I'm also thinking about adding (at least) two functions to
Module::Build's API in the subclass (doc's based on those from

       This method returns a hash reference indicating whether a version
       dependency on Apache is satisfied.  The $version argument can take
       any of the forms described in the requires entry in the
       Module::Build manpage.  This allows very fine-grained version

       The returned hash reference has the following structure:

         ok => $whether_the_dependency_is_satisfied,
         have => $version_already_installed,
         need => $version_requested, # Same as incoming $version argument
         message => $informative_error_message,

       If no version of Apache is currently installed, the have value will
       be the string < "<none" >>.  Otherwise the have value will simply
       be the version of Apache installed.

       This method may be called either as an object method (<
       $build->check_apache_status($version) >) or as a class method (<
       Apache::Build->check_apache_status($version) >).

       Like check_apache_status(), but simply returns true or false
       depending on whether Apache statisfies the dependency $version.

       If the check succeeds, the return value is the actual version of
       Apache installed on the system.  This allows you to do the

        my $apache2 = $m->check_apache_version('2');
        if ($apache2) {
            print "Building for Apache 2.x.\n";
        else {
            die "You must have Apache 2.x installed for this module.\n";

       If the check fails, we return false and set $@ to an informative
       error message.

       If $version is any nontrue value (notably zero) and any version of
       Apache is installed, we return true.

       In general you might prefer to use check_apache_status if you need
       detailed information, or this method if you just need a yes/no

I might add a few more as I get into it, but those come to mind right
now.  I think it might be possible to check mod_perl's version with
the existing check_module_version method, but I'll do some more

I'd also like to see if it's possible to add support for building
mod_perl 1.x and mod_perl 2.x modules from the same distribution --
basically put Stas's code into this somewhere.

James Smith <JGSmith@TAMU.Edu>, 979-862-3725
Senior Software Applications Developer,
Texas A&M CIS Operating Systems Group, Unix

View raw message