On Tue, 2003-03-11 at 21:23, Stas Bekman wrote:
[snip]
> > One
> > problem with the above is if you need to support people who have both
> > mod_perl 1.x and mod_perl 2.x on the same system (maybe in cases where a
> > company or ISP would need to run both side by side to support both
> > versions.) The end user could change the PREFIX with which the module
> > is installed and modify their lib path appropriately, installing twice -
> > once for each version of mod_perl, but I think that is a little rough on
> > the end user. One trick I used which seems to work pretty well for me
> > is to have one main module that points to two different mod_perl version
> > specific modules based on whether we are running in mod_perl 1.x or
> > 2.x. For example (untested):
> >
> > in Apache::FooBar.pm:
> >
> > package Apache::FooBar;
> > use vars qw(@ISA);
> > ...
> > if(eval "Apache::exists_config_define('MODPERL2')") {
> > @ISA = qw(Exporter Apache::FooBar2);
> > require Apache::FooBar2;
> > Apache::FooBar2->import;
> > }
> > else {
> > @ISA = qw(Exporter Apache::FooBar1);
> > require Apache::FooBar1;
> > Apache::FooBar1->import;
> > }
> > 1;
> >
> > in Apache::FooBar2.pm:
> >
> > package Apache::FooBar2;
> > use vars qw(@ISA @EXPORT);
> > @ISA = qw(Exporter);
> > @EXPORT = qw(handler);
> > ...
> > sub handler {
> > ...
> > }
> > 1;
>
> But it seems that you are delegating the problem of figuring out what module
> to load to run-time.
That was actually the point of doing it that way. We then have one set
of installed modules which can determine their version at run-time,
instead of having to install two copies of the module. And since the
use only happens once, there shouldn't be a big performance penalty
(well, besides any @ISA lookups for inheritance.)
> We have already committed to having mod_perl 2.0 modules
> to go to Apache2/ subdir and the Makefile.PL will do that automatically in the
> future (for those systems where mp2 is in Apache2/) so this is not an issue.
> Since when you start your mod_perl 2.0 you have 'PerlModule Apache2' it'll
> pick the right version.
>
> Installation wise, let's take Apache::Peek as an example. It includes two
> difference implemenations for each modperl. So if we want to install it for
> mp1 we do:
>
> % perl Makefile.PL && make install
>
> For mp2, we do:
>
> % perl -MApache2 Makefile.PL && make install
>
> and that's all you have to do. The run time will pick the right version.
>
Ok, I'm confused. So you mean that using -MApache2 it would install in
the Apache2 directory, then rely on use Apache2; in the conf to make it
use the right version (like what is done with the core mod_perl
modules?) If so I would tend to agree, this is a better idea than doing
it run-time in most cases. You still have to install the module twice,
but other than that it would work transparently with two versions of
Apache/mod_perl on the box (which is really what I was thinking of
before.)
> The only problem is CPAN.pm, which I'm trying to resolve using an env var. In
> Apache-Peek's Makefile.PL I have:
>
> my %args = map {split /=/, $_ } @ARGV;
> if ($ENV{MOD_PERL2} || $args{MOD_PERL2}) {
> #warn "Looking for mod_perl 2.0";
> require Apache2;
> require mod_perl;
> if ($mod_perl::VERSION < 1.99) {
> die "You don't seem to have mod_perl 2.0 installed";
> }
> $mp_version = 2;
> } else {
> require mod_perl;
> $mp_version = 1;
> }
>
> so now if we want to build/install for mp2 we can do:
>
> % perl Makefile.PL MOD_PERL2=1 && make install
> or
> % MOD_PERL2=1 perl Makefile.PL MOD_PERL2=1 && make install
>
> So here we have a support for CPAN.
>
> Of course you can start CPAN as:
>
> % perl -MApache2 -MCPAN -eshell
>
> but this is more cumbersome.
>
Hmm. Not sure that I have any other ideas on this one. Maybe prompt
(with a timeout?) in the case where -MApache2 was not used or MOD_PERL2
defined, but both mod_perl 1.x and 2.x are installed? Maybe could also
allow a MOD_PERL1 just to avoid the prompt for people installing a bunch
of modules on systems with both.
[snip]
> > The only problem that I have run into with this is the line:
> > if(eval "Apache::exists_config_define('MODPERL2')") { ... }
> >
> > This just doesn't seem to be very clean to me, and fails for mod_perl
> > 2.x if the end user doesn't have either a PerlModule Apache::ServerUtil
> > or use Apache::ServerUtil in their Apache configuration, but I haven't
> > yet found a better way to determine the version of mod_perl in all cases
> > (most ways require a request object, which doesn't exist when the module
> > is first used, suggestions welcome.)
>
> yup you have to explicitly require Apache::ServerUtil, without relying on user
> loading it (you can simply:
>
> eval {require Apache::ServerUtil}
>
> But a much cleaner and simpler way is to just check the VERSION:
>
> require mod_perl;
> if ($mod_perl::VERSION < 1.99) {
> ...
> }
>
> It looks that we can make it working without adding version numbers to the
> package names. We just need to work out a clean methodology, convenient to
> both developers and users.
>
For some reason I thought I had tried that and there was a problem with
checking that way, but when I went back just now and tried again looks
like that works fine. Thanks!
--
Nathan Byrd <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
