Randy Kobes wrote: [...]
I think it is a ModPerl::BuildMM thing - this patch ======================================================== Index: lib/ModPerl/BuildMM.pm =================================================================== RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v retrieving revision 1.12 diff -u -r1.12 BuildMM.pm --- lib/ModPerl/BuildMM.pm 11 Sep 2003 01:31:22 -0000 1.12 +++ lib/ModPerl/BuildMM.pm 28 Nov 2003 04:24:26 -0000 @@ -235,7 +235,7 @@ #unless already specified with \$(INST_LIB) #or already in Apache2/ unless ($v =~ /Apache2/) { - $v =~ s|(blib/lib)|$1/Apache2|; + $v =~ s{(blib)(/|\\)(lib)}{$1$2$3$2Apache2}; }
$pm->{$k} = $v; ================================================================== arranges for everything to be put under an Apache2/.
Cool. Though, it's probably easier to read:
$v =~ s{(blib([/\\])lib)}{$1$2Apache2};
or even:
$v =~ s{ (blib[/\\]lib) }{ catdir $1, 'Apache2'}xe;
I thought there is at least one more variation of the dir separator, wasn't it ':'?
One consideration about this - if someone has a Win32 build under the current system (where some files are under an Apache2/, and others aren't), and then installs a build with a patch like above applied where everything gets put under an Apache2/, there'll be duplicates of some files. I think using Apache2.pm will pick up the newer files installed under an Apache2/, in preference to the older ones which weren't, as @INC will have D:/Perl/site/lib/Apache2 before D:/Perl/site/lib, so that should be OK. However, perhaps we should think about unlinking the old files not under an Apache2/?
Sure, we can arrange that, via the .packlist, like we do for Apache::test in Apache::Test. Though it's dangerous. Consider the following scenario.
1) Install a fresh perl 2) Install mp2 w/o Apache2 3) Install mp1 which now overwrites some of the mp2 files 4) Install mp2 w/ Apache2 and uninstall files not under Apache2
results - you will ruin the mp1 install from (3).
In the test suite we make sure that we load files from Apache2/ first. Users can do the same, in which case there is no problem. There is no problem if someone installs into Apache2/ and then decides to install into the main @INC. When this happens Apache2.pm will be rewritten not to prepend Apache2 dirs into @INC.
So may be let's just keep it there.
On a related note we don't handle mp2 man pages properly and they will overwrite mp1 ones if the names are the same. Moreover, since the glueing of the pods to .pms happens quite late, MM doesn't even generate man pages for those files. We probably will need to add a new rule to make the manpages after glueing the pods. But this can wait, unless someone wants to tackle that now.
Does the ppm that you maintain include startup.pl or some other file, where we could include 'use Apache2;' on behalf of users? I guess they will still have to include it from httpd.conf, unless you supply the latter and we should just put it there then.
No, it doesn't include a startup.pl - I had thought about that, but was worried about messing with potentially already-present files. What I could do though is, in the post-install script that installs mod_perl.so, have a warning printed out, like you get when building mod_perl, to use Apache2 somewhere.
Though we can include startup-sample.pl or something like that, which can load Apache2, and may be a few basic modules, like in the docs. On a second thought it's probably better not to do anything behind the scenes, users are better off figuring out that they need to load Apache2 and learning on the way why they need to do that. Otherwise things will work, but users won't understand how mp2 .pms co-exist with mp1 .pms with the same names.
__________________________________________________________________ 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
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
