[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apreq-dev
Subject:    [ar2] PATCH: Set PERL_PATH correctly in Makefile.PL
From:       "Edward J. Sabol" <sabol () alderaan ! gsfc ! nasa ! gov>
Date:       2003-12-11 5:28:39
[Download RAW message or body]

In a previous e-mail I wrote:
> The PERL_PATH constant in Makefile.PL is defined to be $Config{perlpath}.
> However, if you rename or move the perl executable after you build it, then
> $Config{perlpath} will not point to the perl executable being used to
> invoke Makefile.PL. Frankly, I don't think this is an uncommon occurrence.

Since ExtUtils::MakeMaker obviously gets this correct, I thought I'd
investigate to see how it does what it does and come up with a patch to fix
this problem. I think this patch implements the canonical Perl method of
determining the path to the Perl executable currently being run.

Could someone please test this on WIN32? If this works on WIN32, I would
appreciate it if someone would apply the following patch to the httpd-apreq-2
CVS repository.

Hope this helps,
Ed

Index: Makefile.PL
===================================================================
RCS file: /home/cvspublic/httpd-apreq-2/Makefile.PL,v
retrieving revision 1.8
diff -u -r1.8 Makefile.PL
--- Makefile.PL 7 Nov 2003 20:05:19 -0000       1.8
+++ Makefile.PL 11 Dec 2003 05:17:48 -0000
@@ -4,9 +4,16 @@
 use warnings;
 
 use Getopt::Long qw(GetOptions);
-use Config;
+use ExtUtils::MM;
 
-use constant PERL_PATH => $Config{perlpath}; # XXX
+use vars qw($mm);
+
+BEGIN {
+    local @ARGV = ();
+    $mm = ExtUtils::MM->new({ 'NAME' => 'libapreq2' });
+}
+
+use constant PERL_PATH => $mm->{PERL};
 use constant WIN32 => ($^O =~ /Win32/);
 
 sub test_prereq {
[prev in list] [next in list] [prev in thread] [next in thread]