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:
I guessed I was looking at the result of automated buildDue to the large volume of modules on CPAN, ActiveState uses an automated build system for their ppm packages...
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 <[EMAIL PROTECTED]> 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
