httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov>
Subject Re: libapreq2-2.02-dev build problems with Perl 5.6.1
Date Wed, 18 Feb 2004 20:42:42 GMT
> Consistency across the various apache/perl related projects is
> important.  As developers it doesn't make our maintainence work
> any easier if we can't get together and adopt a common solution.

OK, that makes sense.

> Right now, it seems to me that the common solution among Apache::Test,
> mp2, and libapreq2 is to rely on Config.pm for the full path to perl.
> So IMO you need to either make the case that it's better for apreq2 to
> break away from what the other projects are doing, or that all three
> should switch to EU::MM.

Well, I really think all three should switch to using EU::MM's method, but
I'm lacking the historical context of why the Apache folks decided not to use
EU:MM's method for determining the path to Perl, so I doubt I can effectively
argue my case. (If anyone can point me to the appropriate thread or threads
in the Apache mailing list archives in which this was discussed, I'd be
grateful.) The only argument I can make is here's a common case in which
$Config{perlpath} doesn't work and EU::MM does.

> My personal opinion is that EU::MM is doing the right thing (by
> either accepting a full path in $^X, or searching your environment's 
> $PATH for $^X before resorting to Config.pm)

I'm grateful to hear that at least.

> but before I'm willing to +1 a change, I need to see evidence that all our
> Apache::Test tests will still run successfully if we adopt your EU::MM
> patch.

Yeah, the Apache::Test tests will also fail. A similar change needs to be
made to Apache::Test, or rather, one of the modules Apache::Test uses or
inherits from. I tracked down the exact location last December, but I forget
exactly which one... Somewhere in the Apache::* modules, the value for the
full path to Perl inherited from EU::MM is explicitly overriden to
$Config{perlpath} with no comment explaining the reasoning for this seemingly
deliberate change.

Mime
View raw message