You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by "Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov> on 2003/12/11 06:28:39 UTC
[ar2] PATCH: Set PERL_PATH correctly in Makefile.PL
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 {
Re: [ar2] PATCH: Set PERL_PATH correctly in Makefile.PL
Posted by Stas Bekman <st...@stason.org>.
Edward J. Sabol wrote:
> Randy wrote:
>
>>Thanks, Ed - the above works fine on my Win32 system.
>
>
> Thanks for testing it, Randy.
>
> Unfortunately, this patch doesn't solve the identical problem with "make
> test". Apache::TestMM is generating the t/TEST scripts incorrectly.
> Apache::TestMM wraps ExtUtils::MakeMaker, so you'd think it would get it
> right, but it also inherits some functionality from Apache::Build. And
> Apache::Build overrides ExtUtils::MakeMaker's value of $(PERL) with it's own
> value obtained from my old nemesis, $Config{perlpath}. From the code, it
> would appear that Apache::Build is doing it intentionally, but the reasoning
> eludes me. And it's not clear if the problem should be fixed in Apache::Build
> or just in Apache::Test. Perhaps I should continue this aspect of the
> discussion to test-dev@httpd.apache.org?
>
> Or I could just break down and ask my system administrator to change
> Config.pm to have the correct value for $Config{perlpath}... Nah, that would
> be too easy! :-)
The issue of $^X vs. $Config{perlpath} has been discussed many times,
especially on p5p and it was never resolved. Therefore if you have a robust
solution a patch against modperl-2.0/lib/Apache/Build.pm would be very
welcome. Please post it to the modperl dev list.
__________________________________________________________________
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
Re: [ar2] PATCH: Set PERL_PATH correctly in Makefile.PL
Posted by "Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov>.
Randy wrote:
> Thanks, Ed - the above works fine on my Win32 system.
Thanks for testing it, Randy.
Unfortunately, this patch doesn't solve the identical problem with "make
test". Apache::TestMM is generating the t/TEST scripts incorrectly.
Apache::TestMM wraps ExtUtils::MakeMaker, so you'd think it would get it
right, but it also inherits some functionality from Apache::Build. And
Apache::Build overrides ExtUtils::MakeMaker's value of $(PERL) with it's own
value obtained from my old nemesis, $Config{perlpath}. From the code, it
would appear that Apache::Build is doing it intentionally, but the reasoning
eludes me. And it's not clear if the problem should be fixed in Apache::Build
or just in Apache::Test. Perhaps I should continue this aspect of the
discussion to test-dev@httpd.apache.org?
Or I could just break down and ask my system administrator to change
Config.pm to have the correct value for $Config{perlpath}... Nah, that would
be too easy! :-)
Re: [ar2] PATCH: Set PERL_PATH correctly in Makefile.PL
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 11 Dec 2003, Edward J. Sabol wrote:
> 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 {
>
Thanks, Ed - the above works fine on my Win32 system.
--
best regards,
randy