perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: mod_perl2.pm
Date Tue, 01 Nov 2005 13:42:37 GMT


Torsten Foertsch wrote:
> Hi,
> 
> is this really necessary in mod_perl2.pm?

I think the decision was made because a ton of legacy applications (like
CGI.pm) would be looking for $mod_perl::VERSION to decide which generation
they were after.  whether this is a good idea or not... well, taking it away
now is probably a bad thing, so let's keep it, especially since that's not
the real problem...

see, $mod_perl::VERSION would report as a 2.0 version if someone
specifically loaded mod_perl2.pm.  now, there's no reason for libapreq-1.33
to be doing that since it's specifically for mp1, which means...

> 
> $mod_perl::VERSION = $mod_perl2::VERSION;
> $INC{"mod_perl.pm"} = File::Spec::Functions::devnull(); 
> 
> It makes libapreq fail to build when mp1 and mp2 are installed.
> 
> 0 r2@opi:~/work/libapreq-1.33$ perl Makefile.PL
> mod_perl 1.x ( < 1.99) is required at Makefile.PL line 34.
> BEGIN failed--compilation aborted at Makefile.PL line 36.

the problem is actually in Apache-Test - Apache::Test tries to load up a
bunch of mp2 classes when it itself is loaded, thus taking over the
mod_perl.pm slot in %INC.  we've run into this problem before with
$mod_perl::VERSION incorrectly lingering and have tried to correct for it,
but apparently it didn't work.

so, please try the attached patch to Apache::Test.  hopefully this fixes
things once and for all (without breaking more stuff :)

--Geoff

Mime
View raw message