Installing standard Unix software

Question

I'm not sure I know the right question to ask...maybe someone can help me. What I'm eventually trying to do is to work with a Perl-based system on my Mac (Mac Snow Leopard); I need the Apache2 Perl .pm files available. They seem to be in /System/Library/Perl/Extras/5.10.0/darwin...but although this is in my path, referencing the packages as Apache2::Request (for example) does not work because of the path names of the library.
I've tried installing Apache from source, and make install appears to get confused by the fact that there's already an Apache installation that ships with the OS.
I'm sure there are lots of things I just don't understand here. Can someone point me at a resource that explains how the Apple versions of Unix software interact with potentially newly-installed versions (or explain it to me)? How much trouble can I get myself into by installing packages (Apache is the example above, but there are/may be others) that ship also with Mac OS? Should I be starting by re-installing Perl from scratch, changing my Perl include path, and pretending all the Apple software just doesn't exist? Should I just go buy a Linux box?
Thanks.

Answer 1

rm50 wrote:
First, the Apache2::Request library is still (not surprisingly) not findable by Perl, since it doesn't live in my standard INC. That seems odd (it lives in /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level/DBI/Gofer). Is there something going on, or should I just make sure my @INC points there?
It doesn't live there. It isn't installed at all. I had to install it via:
sudo perl -MCPAN -e 'shell'
install Apache2::Request
At some point, it stopped and asked me if I wanted to run the tests. The first time I accepted the default and the tests failed. Then I did the install again and it quickly got back to the point of asking about the tests. This time, I told it to skip the tests. Those CPAN tests often fail due to very specific configurations required.
Then I added a new script to test this module:
use Apache2::Request;
$req = Apache2::Request->new($r);
@foo = $req->param("foo");
$bar = $req->args("bar");
$req->content_type("text/html");
$req->print("Bar is $bar
It failed. After a little Googling it appears you need a specific module to support this. That module seems to be there already, so I added it to /etc/apache2/httpd.conf.
LoadModule apreq_module libexec/apache2/mod_apreq2.so
Restarted Apache and it worked this time. Moving on...
Also, when I tried to install XML::LibXSLT, the perl makefile complains that I only have version 1.69 of LibXML, not 1.70. Can I safely install the 1.70 LibXML.pm on top of the 1.69 that lives in my system area, or should I put it somewhere in my INC path before the system version? What would you suggest?
Actually, that was just a warning. I let CPAN run and I now have LibXML. CPAN appears to put things into /Library/Perl. That seems like a logical place. On MacOS X, while there is a /usr directory, there is also a MacOSX equivalent /System. The same goes for /usr/local. Things that you might expect to go into /usr/local might sometimes be in /Library. I guess it depends on how "Mac-friendly" a particular package might be. Many are too difficult to reconfigure and are better left to /usr or /usr/local. I haven't tested XSLT or XML because I don't have any XSL files handy on this machine. But I don't expect it to have problems.
Keep in mind that if you intend to deploy anything on a different system (such as a shared hosting provider), that other system must have the same modules. The big web hosting companies usually have all the bells and whistles, but you never know. You usually cannot install Apache modules or make most system configuration changes on a shared provider.
You can install CPAN modules anywhere you want and tell Perl about the new library path. I normally do that rather than just letting CPAN do it all, but this is a throwaway 10.6 install on this machine so I don't care. I like to keep my Perl projects as self-contained as possible. I don't think that is really possible with mod_perl though.