I suspect there's a way to fix the issue, but my general advice is this: don't be a slave to running the tests if you already have some way to know if the module is working.  It's fine to force install rather than spend hours fighting with a test setup.

- Perrin

On Tue, Sep 10, 2013 at 8:11 PM, Thomas M. Payerle <payerle@umd.edu> wrote:

Our site uses networked file systems and the same code base is available on many systems.
We have multiple versions of e.g. apache and perl installed, and e.g. init.d scripts will
look up the version of apache to use for a particular server and start that version, out
of the several installed on the system.  For perl, users/scripts would specify the version
of perl they wanted.

For the most part, this works well.  Apache modules e.g. would go into the apache build
tree for that particular apache.  Same with perl modules.

Except mod_perl depends on both apache and perl version, and wants to stick stuff in
both apache and perl trees.  Which means how do I make sure I get the mod_perl built for
the particular perl/apache combination I am using?

I thought I had figured this out; put mod_perl in its own tree, with subdirectories for
mod_perl version, apache version, and perl version.  During the mod_perl install, in
the "perl Makefile.PL" phase, I specified PREFIX to where I wanted the perl bits to go,
and used  MP_AP_DESTDIR to specify where I wanted the apache bits to go.

To use it, I had to specify the full path to mod_perl.so, and use a PerlSwitches configuration
directive so that the mod_perl related *.pm files, etc. would be found, but otherwise
everything seemed happy.  At least some simple test scripts using ModPerl::Registry and a
simple handler module of my own, and they worked.

Then I tried installing Apache2::Request.  OK, after a little work I managed to get it to
find the apache2 - mod_perl header files from my non-standard location, but tests were
still failing.  It looks like Apache::TestConfig is not finding my mod_perl.so, and so
the test httpd configs don't get mod_perl, which understandably causes things to fail.  So
it looks like I need some more hacks to the mod_perl code.  It looked like I might be
able to add a path to find_apache_module, which is fine if that is more or less all it is.
But I am also concerned that I might be headed very quickly into some very deep stuff, and
as I know relatively little re the Apache::Test* suite, was wondering if anyone had
any advice or suggestions?

Thanks in advance for any assistance.

Tom Payerle
IT-ETI-EUS                              payerle@umd.edu
University of Maryland                  (301) 405-6135
College Park, MD 20742-4111