finding mod_perl shared object on win32

Randy Kobes wrote:
> 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:stas@xxxxxxxxxx http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com