Geoffrey Young wrote:
>>>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?").
I would argue that there is another case that is not as rare;
dependencies. If a user tries to install my module via CPAN I would like
it to be able to determine what other things need to be tracked down.
And these dependencies may be different depending on the target mod_perl
API version.
> 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.
Oh, I completely agree. I like M::B's idea of 'build_requires' and it
would be nice if it also had a 'test_requires' as well.
> 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.
Ooohhh, that would be nice :)
> 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 :)
I don't have a lot of time right now to help, but if he has any ideas or
something that partially works, I'd be willing to be a sounding/testing
board.
> 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.
I think you convinced me of how bad an idea this is, so I turn my head
and walk the other way :)
--
Michael Peters
Developer
Plus Three, LP
