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 Thu, 19 Feb 2004 09:18:42 GMT
> 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:
> 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

>> 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};

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

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

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

Mime
View raw message