Stas Bekman wrote: > We have a need to be able to load mp2 modules at the server startup > (e.g. APR::Error), but we are dependent on the users to load > Apache2.pm, without which mp2 modules won't be found (if installed > into Apache2/).
in the test suite or in real life? > So here is a proposal how to solve this problem. > > mod_perl will load Apache2.pm by itself, as soon as it starts > perl. so Apache2 would be called after the interpreter is launched but before, say, a <Perl> or PerlLoadModule directive is run? that would be a requirement I would think. > For most people it'll just save them the need to type > > PerlModule Apache2 for the moment. as people move away from mp1 the Apache2 hack will disappear. I wouldn't expect to need it at all anyplace other than development, so I would suspect that for the majority of eventual installations (1 dev box versus a production cluster) we would be cluttering @INC for no reason. > > For those who will want to adjust @INC before Apache2 is loaded (to find > a different mp2), there is PerlSwitches, which must be set before perl > is started. So lets say you want to load your private mp2 (installed at > /home/stas/perl5/) on a system where there is already mp2 installed > under /usr/lib/perl5, so your httpd.conf will look like: > > LoadModule perl_module modules/mod_perl.so > PerlSwitches -Mlib=/home/stas/perl5/ I'm not sure I follow how this. if your mp2 install is in /home/stas/perl5 then won't the load of APR::Error be found in @INC _before_ the -Mlib call, therefore using a version from someplace _other_ than -Mlib? if so, you would almost always load the wrong version (or at least not the one you thought you were pointing at with -Mlib). if not, then why not just let the users specify PerlModule Apache2 themselves without the magic? > > So the only inconvenience it creates is that you can't do it from your > startup.pl, but must use PerlSwitches. PERL5LIB env var is not > applicable as it's ignored by Perl when -T is in effect. > > Can anybody see any potential problems with this solution? perhaps. once you load Apache2 @INC is forever tainted with whatever Apache2.pm finds. granted, the -Mlib statement will give the new lib priority, but it still feels a bit strange to have @INC reflect stuff I may not be interested in - for instance, would this make it more difficult to track down problems where there the -Mlib install is incomplete so perl picks mix-and-match mp2 packages from lib and lib/Apache2? I'm not convinced this is a good idea, at least not yet :). but if there is no way to work around the APR::Error thing then I think what we really need is a way to remove Apache2 entries from @INC. that way a user can completely cancel the effects of Apache2 if they want, not merely gloss over it with extra libs. another suggestion is to make it a compile-time option, loading Apache2 by default but giving the ability to turn it off. this seems a bit cleaner than making an anti-Apache2 module or directive that people need to remember to call if they _don't_ want Apache2 messing with their @INC. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
