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


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

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 
> 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.
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.
>     The other way to fix this issue is how 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 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     mod_perl Guide --->

View raw message