sorry it took so long to respond i had some 'real work' issues :) anyhoo, i am
really torn on this one. I still think mod_perl should immediately just switch
to the new-style .so - mod_perl has always been the closest darling to apache so
it only makes sense that it follows the bleeding edge. If the mod_perl
instructions so mod_perl.so everywhere then no-one should be confused... they
might double take, but they'll get over it fast.
So what'dya think randy - i'll go with your gut feel - and my patch will be
there when things are more comfortable.
sterling
Randy Kobes wrote:
> ----- Original Message -----
> From: "John K Sterling" <[EMAIL PROTECTED]>
> To: "Randy Kobes" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, December 22, 2000 11:07 AM
> Subject: Re: [PATCH] win32 module names now like unix
>
> >
> >
> > Randy Kobes wrote:
> >
> > > would people get
> > > too confused if a mod_perl.so was installed if they were building
> > > against apache_1.3.12, say? Should we have an Apache version
> > > check in there to use mod_perl.so for 1.3.15 and ApacheModulePerl.dll
> > > for pre-1.3.15?
> >
> > Great point - this would also allow us to look in the correct place for
> the
> > ApacheCore.lib file depending on the version. Makefile.PL could patch
> these
> > things up - and that would simplify everyone's problems except for.... dah
> dah
> > dah... the documentation. It would be pretty wierd to have 2 sections in
> the
> > docs 1 for pre-1.3.15 one for post 1.3.15 but i suppose it would work.
> >
>
> Hi,
> It would be wierd to have this, but I guess that's life now ....
>
> > > The "advantage" to Windows, though, is that
> > > it forces you to upgrade often, so adopting the 1.3.15 convention
> > > right away might not cause a problem ....
> > >
> >
> > true - and it won't actually break it to use mod_perl.so in pre-1.3.15
> builds,
> > it'll just be different from the standard modules naming.
> >
> > i could go either way, though i think i advocate switching immediately to
> > mod_perl.so for consistency - and before we know it - this convention will
> be
> > the norm (especially considering all win32 users will most likely flock to
> > apache 2.0 when it comes out and should move to 1.3.15 asap).
> >
> > thoughts? should we put version support into Makefile.PL and have 2
> > installation sections in the docs (pre/post 1.3.15) or just move to the
> new
> > convention and recomend an apache upgrade to 1.3.15 (which has a bunch of
> new
> > support for win32 users anyway)?
> >
> > sterling
>
> I think too advocating the switch is a good idea - as you say, most
> Win32 people will probably move to 1.3.15 anyway - apparently it
> will now be labelled as "initial release quality", rather than
> "beta release quality". But perhaps we should not force the issue,
> if reasonable. What we could do is
> - search for the Apache lib in the directory according to the Apache
> version, as in your patch;
> - let mod_perl build an ApacheModulePerl.dll for now, and
> change this to build a mod_perl.so later on, when this new
> convention is the norm. This way, people not building with
> 1.3.15 won't panic when they can't find ApacheModulePerl.dll, and
> those that are using 1.3.15 are probably aware of the needed
> name change;
> - if the user elects to install automatically with the INSTALL_DLL
> attribute, copy ApacheModulePerl.dll to the indicated directory
> as mod_perl.so or as ApacheModulePerl.dll, according to the
> Apache version;
> - if the user elects to install manually, they're probably aware
> of the new convention if they're using 1.3.15; we could print out
> a message from Makefile.PL that ApacheModulePerl.dll must
> be copied to $APACHE/modules/mod_perl.so if 1.3.15 is being used.
> More generally, we could have Makefile.PL print a about
> this impending changeover;
> - update the docs accordingly;
>
> Does this sound reasonable?
>
> best regards,
> randy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
