On Wed, Aug 20, 2003 at 09:09:40AM -0400, [EMAIL PROTECTED] wrote:
> !Once perl has been installed, we get the name of the perl
> !executable from $^X. Actually, during the build process we should be
> getting
>
> The name ndbgperl.exe never was checked for an installed
> usevmsdebug PERL_ROOT.
Err, I don't understand what that means.
> !the name of the perl executable from $^X. Is $^X not getting set
> !properly? Is lib/File/Spec/t/rel2abs2rel.t working? That relies on $^X.
>
> If I turn on C<$trace = 2;> inside of MM_VMS.pm::find_perl() it
> seems that it prefers miniperl.exe and then the s/miniperl/perl/i
> turns miniperl.exe into perl.exe (even though there is no perl.exe
> file in a usevmsdebug build of perl). lib/File/Spec/t/rel2abs2rel.t
> will work OK if I have set default'ed to an absolute path, but it
> will fail if I have set defaulted to a rooted logical named path.
> That could be a problem with $^X. Note that for an installed
> usevmsdebug NDBGPERL.EXE it is run from PERL_ROOT which is a
> rooted logical name.
>
> !If so then there's a deeper problem with the init_PERL/find_perl logic.
> !
> !Or is this all to work around the dubious "find miniperl" logic?
> !
> ! # Define 'FULLPERL' to be a non-miniperl (used in test: target)
> ! ($self->{FULLPERL} = $self->{PERL}) =~ s/miniperl/perl/i
> ! unless $self->{FULLPERL};
>
> The second portion of my patch addresses this problem and changing the
> regular expression substitution to C<s/miniperl/${ndbg}perl/i> is what
> allows the regression tests to pass. If I omit that substitution but
> retain the push of the name 'ndbgperl' onto the @perls stack then
> MakeMaker can set the FULLPERL macro properly in a descrip.mms for a
> CPAN module being built against an installed
> usevmsdebug PERL_ROOT.
>
> Have I explained the patch adequately?
I think so.
The one real problem I see in MakeMaker WRT ndbgperl is the miniperl <-> perl
conversion logic in init_PERL(). Admitadly a hack. But its a hack only
necessary during the build of Perl itself. It prefers miniperl over perl.
It also assumes that if you find miniperl.exe you've found perl.exe.
But it *should* prefer $^X over everything. However, to add to the complexity
of the problem, VMS->find_perl has an additional hack to look at relative
paths first. This is probably why ndbgperl.exe isn't getting picked up from
$^X (since its always first in the perl search path going into find_perl)
since its probably absolute.
I'm not inclined to generalize that special case bit of hackery to handle the
case when perl.exe does not exist. The logic is already dubious enough.
Hacks on top of hacks on top of hacks all for the special case of building
the core.
We control the build system and can simply say that miniperl.exe and perl.exe
will always exist. The VMS build system can handle this problem itself by
copying ndbgperl.exe to perl.exe (but not installing it) thus making it work
consistently with all the other build systems. I find this much more
desirable than having MakeMaker start having to deal with yet more
inconsistencies with how perl builds on various OS's. Once its installed
you can call it anything you want.
To put it another way, I'm tired of putting Yet Another Special Case To Fix
A Special Case into MakeMaker. Not when that special case can be so easily
eliminated at the source.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
Monkey tennis
