httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: libapreq2-2.02-dev build problems with Perl 5.6.1
Date Thu, 19 Feb 2004 07:36:55 GMT
Edward J. Sabol wrote:
>>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.

Really, what's is needed is some equivalent of File::Spec which will give you 
*one and only* way to get the right perl path.

You can see that it's not the first time I have to deal with it:

In particular a long thread at:

with another thread linked from it:

I hope you have enjoyed reading through it and realized what a mess it is. And 
that there is no right away at the moment.

 > Next, I patched Makefile.PL to use ExtUtils::MM instead of $Config{perlpath}.
 > I posted this patch on December 11th, but it was never applied to the CVS
 > repository. I need this patch or it won't use the correct version of Perl.

Sorry, I don't remember the patch and I can't find it here:
Can you please find the right link, repost the patch? Thanks.

> 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.) 

Please be more specific. Are you talking about If so it has the 
explanation of why this is done:

sub fixup {
     #make sure we use an absolute path to perl
     #else Test::Harness uses the perl in our PATH
     #which might not be the one we want
     $^X = $Config{perlpath} unless -e $^X;

You could be right about the other two places where it's used.  We should 
switch to $^X I think.

> The only argument I can make is here's a common case in which
> $Config{perlpath} doesn't work and EU::MM does.

Beg your pardon, what EU::MM function are you talking about?
ExtUtils::MakeMaker::find_perl()? It's not a public API function to find perl.

sub fixup {
     #make sure we use an absolute path to perl
     #else Test::Harness uses the perl in our PATH
     #which might not be the one we want
     $^X = $Config{perlpath} unless -e $^X;

>>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
> 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.

I'm not sure which place you are talking about, besides 3 places I've listed 

To sum things up, we keep on changing the way perl is found every time a new 
bug report is coming in, breaking it for the other users. I'd love to have one 
and only way that will always work.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message