>> as a community we really ought to figure out the "right" way to do this
>> and abstract it into something everyone can just cut-and-paste. or,
>> better, include it as a package in both mp1 and mp2.
>
>
> I think the "best" way might be to look to Apache::Test. Figuring out
> which one to use at run time is easy and well documented but the
> install/testing time is the tricky bit. I don't know if it's currently
> available, but is there a way to query Apache::Test to find out which
> version of mod_perl it will run against (since A::T figures this out
> when it's installed right)?
well, kinda.
what Apache-Test does is cache the data you entered when you ran 'make
test'. for example, if you built Apache-Test as
$ perl Makefile.PL -apxs /my/httpd-2.1-binary
then A-T would never again ask you "what httpd do you want to use?" when,
say, a CPAN module uses A-T for its tests and the user forgets to specify
-apxs. of course, insert -httpd, APACHE_TEST_HTTPD, etc for -apxs.
now, I've always maintained that this is a very bad idea whose
implementation is still the source of the occasional frustrated user
(besides myself), but I won't go into that here :) but I think it's even
worse for what you're after.
what we all want is a way for 'perl Makefile.PL' to know whether it's being
built against mp1 or mp2 for the (rare) module that cares at build-time. a
good example is for directive handlers, which are 100% runtime for mp2 but
require build-time XS-fu for mp1. if a user has mp1 and mp2 on the same
box, A-T will likely come from mp2 which would cause build-time inspection
of A-T libraries to fail for mp1 installs if we chose the A-T route. worse,
there will be no clear path for a confused user to follow when things don't
go as they wish ("what does Apache-Test have to do with where Apache::Foo
from CPAN installs?").
it also assumes that your mp1 user will actually have A-T installed. next
time we get together I'll need to rant a bit about how I can't stand modules
that refuse to _build_ because my @INC lack things they need only for their
_test_ environment.
in short, using a test-environment variable to affect build or runtime
environments breaks all sorts rules, if only those that I've made up and
believe in myself :)
that said, my personal preference would be a ModPerl::MM library that was
distributed with both mp1 _and_ mp2. modules that are mp2-based could
enforce mp2 via what they should already be doing:
ModPerl::MM::WriteMakefile(NAME => 'My::MP2::Foo');
modules that are both mp1 and mp2 but need to know at build-time should be
able to do something as simple as
my $version = ModPerl::MM::Query::version_query();
before the call to WriteMakfile(), which would launch an interactive
dialogue saying something like
this module can be installed for either mod_perl 1.0 or mod_perl 2.0
but you need to choose now: [1/2]
and then leave you do do what you require.
mp1-only modules or modules that require no build-time interaction could
simply forget about querying all together.
anyway, IIRC dorian has done some work on this front. probably not like
what I've just described, but he's done _something_ which is a start :)
of course, there's nothing preventing you from using Apache::TestConfigData
etc now yourself. however, I don't think that is a viable or wise long-term
solution to the issue at hand.
--Geoff
