httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: libapreq2-2.02-dev build problems with Perl 5.6.1
Date Thu, 19 Feb 2004 09:55:48 GMT
Edward J. Sabol wrote:
>>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.
> 
> 
> Thanks for the links. I've read the threads, and I beg to differ. See below.

Absolutely.

>>>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:
>>http://marc.theaimsgroup.com/?l=apreq-dev&w=2&r=1&s=edward&q=b
>>Can you please find the right link, repost the patch? Thanks.
> 
> 
> http://marc.theaimsgroup.com/?l=apreq-dev&m=107112052200922&w=2

Great, thanks!

>>>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.
> 
> 
> My patch does not use that function directly. For libapreq2, I was advocating
> using the equivalent of
> 
>    my $perlpath = ExtUtils::MM->new({ 'NAME' => 'libapreq2' })->{PERL};

Sure, it may work, but it's an overkill. I'd rather call 
ExtUtils::MM->find_perl directly than load the whole MM setup, every time I 
need to get the path to perl.

>>>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 
>>above.
> 
> 
> I misremembered. I was referring to the following snippet in Apache::Build:
> 
>     #when we use a bit of MakeMaker, make it use our values for these vars
>     my %perl_config_pm_alias = (
>         PERL         => 'perlpath',
>         PERLRUN      => 'perlpath',
>         PERL_LIB     => 'privlibexp', 
>         PERL_ARCHLIB => 'archlibexp',
>     );
> 
>     my $mm_replace = join '|', keys %perl_config_pm_alias;
> 
> etc.

That's the change that added this. It has no comments to why it was done. But 
I'm pretty sure it was done for a good reason, usually you don't mess with MM 
just for fun.
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/lib/Apache/Build.pm?r1=1.52&r2=1.53&diff_format=h
In any case, that change doesn't seem to affect anybody (i.e. noone has 
reported any problems with building mp2 related to this).

> As for Apache::Test, in addition to fixup() in Apache::TestRun, there's also
> the following line in write_perlscript() in Apache::TestConfig:
> 
>     print $fh "#!$Config{perlpath}\n";
> 
> and a very similar line in t_write_perl_script() in Apache::TestUtil.
> 
> (Note: It's entirely possible that I'm not looking at the current versions of
> these files.)

Yes, I've mentioned these. We could fix them similar to fixup() to use $^X if 
perlpath is not valid.

>>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.
> 
> 
> Again, I believe that EU::MM fits exactly that requirement, and none of the
> threads you pointed me to seems to disagree with that statement. I agree that
> there are problems with using $^X, but I believe ExtUtils::MM solves those
> problems. That p5p thread to which you pointed me seemingly agrees actually.
> 
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-05/msg00331.html:
> 
>     The other way to fix this issue is how MM_Unix.pm does it:  use
>     File::Spec->canonpath($^X); now you have the fully-expanded
>     pathname of the executing version of perl.  I tested this
>     change, but since test-harness.t worked w/o it, I didn't submit it.
> 
>     I'll happily defer to Michael G. Schwern or anyone else who
>     wants to fix this, as long as the distinction between a command
>     name (which $^X is) and a file pathname (which $^X is not) is
>     maintained.  [See MM_Unix.pm for an idiom that converts $^X into
>     a file pathname].

Does that File::Spec->canonpath($^X) work for you? I guess we could try to:

sub find_perl {
   my $path = File::Spec->canonpath($^X);
   $path = $Config{perlpath} unless -e $path && -f $path;
   die "Can't find path to perl" unless -e $path && -f $path;
   return $path;
}

BTW, what Module::Build uses to figure out a path to perl? (this is a 
replacement for EU::MM in case some of you didn't know).

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message