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 <[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. -- best regards, randy -- 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
