On Thu, 13 Mar 2003, Geoffrey Young wrote:
yeah, I think it's related to the latest change in ModPerl::MM
http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=104432362926275&w=2
removing -MApache2 from the macro solves the problem, but thus makes it unusable for third party modules.
I guess we really need to think harder about third party module support. I know I've struggled with this lately as has Stas, although ModPerl::MM::WriteMakefile seems to sorta work.
maybe we should just revisit third party modules alltogether and come up with a feature list and API, then implement from scratch - possibly as a ModPerl::MM subclass or something.
It is a bit of a quandry ... One thing that I've also noticed is that things are configured so that, if mod_perl.so appears in the installed httpd.conf within a LoadModule directive, this isn't included in the generated httpd.conf. That's the desired behaviour when building mod_perl itself, as you'd want the freshly built mod_perl.so used instead, but for a third party module you do want to load the installed mod_perl.so. One work-around is to have a TEST.PL something like:
======================================================== #!perl use strict; use warnings FATAL => 'all'; use Apache::TestRunPerl();
package MyTest; our @ISA = qw(Apache::TestRunPerl); sub pre_configure { } MyTest->new->run(@ARGV); ======================================================== but perhaps a more transparent way could be devised.
Randy,
I've looked at this issue and I don't see this problem on linux. Admittedly there was a problem with using -apxs which was finding mod_perl.so when it wasn't supposed to, which I've fixed now in cvs.
Currently the logic goes like this (at this moment only relevant to mod_perl 2.0 built as DSO):
1. always ignore the whatever 'LoadModule perl_module path' was found in global httpd.conf (that's what pre_configure() does)
2. look at the build config options, if such exists (which is the case when mod_perl was installed on the system or we are inside the core build), use the information from there
3. otherwise die, saying oops, mod_perl is not installed
Currently I have two perl trees (I have many more but for the purpose of this explanation let's say I have just two): ~/perl/blead and ~/perl/blead-ithreads. I've installed mod_perl using ~/perl/blead-ithreads, but not ~/perl/blead.
Now if I build a 3rd party module with blead-ithreads, it automatically finds mod_perl.so, because it's in BuildOptions. No matter if I provide -httpd, -apxs or nothing at all.
If I build with blead (no mod_perl installed) it finds no mod_perl.so, no matter if I provide -httpd, -apxs or nothing at all.
Now, Randy, can you please tell whether this logic is flowed?
__________________________________________________________________ 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
