Re: Why MP2

[prev] [thread] [next] [Date index for 2004/12/16]

Thanks for the background Randy. I have seen ActiveState get a pretty 
major hammering
in some quarters for their support of Perl , so it's interesting to get 
a more reaoned perspective.

It's a real shame the mod_perl build can't be made hands-off, as it 
seems that would bring so
many Apache::* modules on line with no extra effort, but if these can be 
made available on the
uwinnipeg repository i'm more than happy to live with that ;-)

Re:

> It's odd that Windoze needs a .dll manually installed,
> when on Unixes mod_perl.so is sufficient on its own.

It wasn't the mod_perl.so I was querying, but-

httpd.conf
----------
LoadFile "C:/Prog/Perl/bin/perl58.dll"


It's this bit that differs between the Win and Unix configurations, 
Solaris doesn't need a
separate perl library configured on top of (actually prior to) 
mod_perl.so (presumably
because it's found via the ld library path?)

There definately is a problem with installing mod_perl in a path with 
spaces at the moment.
This was only a week or so ago for me but it's amazing how fast the 
memory goes when you're
frying your brain trying to grapple with a ton of other software. From 
memory there were two
distinct problems.

One was a classic "C:\Program (sic) is not a valid program or batch 
file" type failure to execute
a command. The other was more obscure, i'm struggling here but i'm 
pretty sure one piece that
failed was the post-install script that downloads and installs the perl 
.dll, I think it couldn't find the
Apache installation dir.

Thanks for putting up the packages mentioned. I'm going to go away and 
try these now. What
is the best method to give you feedback, direct mail or is there a 
formal feedback alias for the
repository?

Regards: Colin

Randy Kobes wrote:

>On Wed, 15 Dec 2004, colin_e wrote:
>
>  
>
>>Randy Kobes wrote:
>>
>>    
>>
>>>Due to the large volume of modules on CPAN, ActiveState uses
>>>an automated build system for their ppm packages...
>>>
>>>      
>>>
>>I guessed I was looking at the result of automated build
>>tests. However I naiively thought that Apache and mod_perl
>>were so important to so many users they might get a little
>>extra attention.
>>    
>>
>
>We like to think so :) However, there's quite a few popular
>packages that also require human intervention in the build
>process: GD, libxml2, various database drivers, ... And
>these can be quite time-consuming in maintaining - building
>and updating external libraries, sometimes tweaking things
>that aren't always Win32-aware, interpreting failed tests as
>either trivial failures or something indicative of a
>fundamental problem, and so on. So, from a corporate time
>management and quality point of view, it's understandable
>why ActiveState has the policy they follow in providing ppm
>packages.
>
>Historically speaking, ActiveState (and the perl5
>developers) have done an incredible job in providing a Perl
>on Windows that works as well as it does (given, at times,
>some fundamental limitations of Windows, compared to Unix).
>Developers at ActiveState are quite active in maintaining
>this, both in the core Perl development and, when asked,
>helping us occasionally with pretty tricky problems with
>Win32 mod_perl. Given that, I (and some others) are quite
>willing to provide ppm packages for those modules which
>escape ActiveState's automated build process.
>
>  
>
>>>However, if you install mod_perl via ppm (from our theoryx5
>>>repository, or elsewhere), ppm will register and see it
>>>for subsequent packages that require it...
>>>
>>>      
>>>
>>I followed the install procedure documented at perl.apache.org
>>(http://perl.apache.org/docs/2.0/os/win32/install.html#PPM_Packages).
>>
>>After having been bitten by the fact that the mod_perl
>>installer blows up on pathnames containing spaces, forcing
>>a teardown and reinstall (great...),
>>    
>>
>
>Pathnames with spaces can be a problem - we've tried to
>catch these cases in the mod_perl build, but if we've
>missed something, please let us know. In general, though,
>installing both Perl and Apache in directories that
>don't have spaces may avoid some frustration later.
>
>  
>
>>I installed Perl 5.8.4 and Apache 2.0.52 using their
>>respective .msi installers. I then configured uwinnipeg as
>>a PPM repository, and installed mod_perl from there.
>>mod_perl shows up correctly in PPM as-
>>
>>ppm> prop mod_perl
>>====================
>>    Name: mod_perl
>> Version: 1.99_17
>>  Author: Doug MacEachern <dougm@xxxxx.xxx>
>>   Title: mod_perl
>>Abstract: Embed a Perl interpreter in the Apache/2.0.50 HTTP server
>>InstDate:  14:33:24 2004
>>Location: http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58
>>Available Platforms:
>>       1. MSWin32-x86-multi-thread-5.8
>>====================
>>
>>It's odd that Windoze needs a .dll manually installed,
>>when on Unixes mod_perl.so is sufficient on its own.
>>    
>>
>
>The mod_perl.so (which is actually a dll) that a ppm
>installation fetches and installs is done as a separate
>post-install script because it needs to be installed outside
>of the Perl tree (ie, in the Apache2 modules/ directory).
>There's a few other packages that also do this - libapreq2
>(for Apache::Request and Apache::Cookie) and XML::LibXML (a
>Perl interface to libxml2), to name two.
>
>  
>
>>However as I read your mail, this means subsequent
>>packages dependent on mod_perl should install ok IF they
>>can be made available as PPMs. (It's a shame ActiveState
>>doesn't get this far to enable all those defunct Apache::*
>>PPMs to be built).
>>    
>>
>
>That's right - once mod_perl is installed via ppm, ppm will
>recognize that mod_perl is installed when installing other
>packages that require mod_perl.
>
>  
>
>>>As to the problem of there not being that many Apache-*
>>>ppm packages available, there's at least three options:
>>>
>>>- send me a request for a particular package. I have a
>>>semi-automated setup for making ppm packages, so it's
>>>usually no problem to make one up. I'll look at in
>>>particular doing one for Apache::CGI::Builder tonight.
>>>
>>>      
>>>
>>This is terriffic, and much appreciated. As a newbie the
>>process of getting Apache and mod_perl plus the addons
>>packages running has been pretty painful (actually it was
>>the Solaris compile+install that really drove me nuts). At
>>the moment I have the Apache::CGI::Builder.pm manually
>>pulled out of the .tar.gz download and copied into my Perl
>>library, but it's not working correctly and I can hardly
>>rule out a misinstallation.
>>
>>The particular packages that would be top of my list would be-
>>
>>* Apache::CGI::Builder
>>    
>>
>
>I've placed a ppm package of this (and its prerequisites) in
>our http://theoryx5.uwinnipeg.ca/ppms/ repository. Let me
>know if you have problems installing it. Perhaps such an
>installation (as well as the prerequisites) will fix the
>problem you had. The ppm installation should also install
>html versions of the documentation in the location that
>ActivePerl expects (and so should be available through the
>ActivePerl documentation link on your Start menu).
>
>  
>
>>* Apache::SessionManager, dependent on-
>>    
>>
>
>Also in our http://theoryx5.uwinnipeg.ca/ppms/ repository.
>
>  
>
>>* Apache::Cookie
>>    
>>
>
>This is contained in the libapreq2 package in our repository
>(which also includes Apache::Request). This is one of those
>packages that requires an external dll (actually, two) to be
>fetched and installed - installing libapreq2 via ppm should
>offer to do this for you through a post-install script.
>
>  
>
>>I know I will need some of the ApacheAuth and Apache*LDAP
>>packages at some point as well, but there are a ton of
>>them and i'm not sure which combination I need yet.
>>
>>Thanks for the help. It encourages me to keep trying ;-)
>>    
>>
>
>You're welcome - good luck.
>
>  
>


        -- 
        Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html