On Sun, Dec 21, 2003 at 02:15:12AM -0800, Stas Bekman wrote:
Thanks Michael. That's right, it fails to load the module. That module can't be loaded from the command line, it requires a running mod_perl (unsatisfied symbols), just like most other Apache:: modules. Is this something new or has been like this forever and nobody has ever complained?
Been like this for as long as I've known.
OK, thanks.
Why not use parse_version() instead of trying to load the module?
You'd have to search @INC manually. Its simpler to just let Perl do all that. It also guarantees that the module will compile and that the dependency is really satisfied. Its pretty rare that a module won't compile without a server running. Take, for example, the DBD:: modules.
It's pretty typical for mod_perl modules. Unless a special care has been taken, like an example below. You don't realize you need to do that until you get the requirements on your module failing ;)
It seems that the following workaround happens to make the module successfully load w/o mod_perl.
# so that it can be loaded w/o mod_perl (.e.g MakeMaker requires this # file when Apache::Scoreboard is some other module's PREREQ_PM) if ($ENV{MOD_PERL}) { require XSLoader; XSLoader::load(__PACKAGE__, $Apache::Scoreboard::VERSION); }
I'd go with that. Its good to be able to at least be able to load a module without Apache running.
Yup, we should probably document this in the Apache:: module guidelines.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
