Michael G. Schwern wrote in reply to me:
!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.
Which is incorrect in the case of an installed ndbgperl.exe, hence FULLPERL
winds up being specified as:
FULLPERL = MCR PERL_ROOT:[000000]PERL.EXE
for a CPAN module being added to an NDBGPERL.EXE installed PERL_ROOT.
!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.
For what it is worth: I suspect that the concept of File::Spec->abs2rel()
is flawed on many non Unix systems (basically any system without a unified
file system).
On Unix all directories, including not only the cwd but also the directory
of any path to any file on the system can be found under the '/' root.
Hence the algorithm of abs2rel() of comparing a file path to the Cwd::cwd()
path can work on Unix, and it might also work on for a file path and
a cwd that are on the same "disk drive" on non unified systems like
VMS, Windows, and Mac OS. However, if my VMS PERL_ROOT is on
DKA300:[PERL.]
and my "DEFAULT" or pwd directory is on DKA200:[USER.PPRYMMER] then
asking File::Spec::VMS.pm::abs2rel() to compare cwd() returns to
an absolute spec like either PERL_ROOT:[000000]NDBGPERL.EXE or to
DKA300:[PERL]NDBGPERL.EXE is just not going to prove fruitful since
no amount of up one directory hopping ( [-] in native VMS speak,
../ in Unix speak) is going to get from DKA300: over to DKA200:.
!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.
I think there may be another problem. Consider what you have in
init_PERL in the absence of my patch, just after plunking $thisperl
into the @perls array you've added these names:
2330 push @perls, map { "$_$Config{exe_ext}" }
2331 ('perl', 'perl5', "perl$Config{version}");
Does it not strike you as odd that there is a $Config{exe_ext} but
there is not a $Config{perlname} variable that could be consulted
as the authoritative name for installation, for startperl purposes
et alia?
!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.
You suggestion here will only address the needs of two tests in the
test suite and will also render the ability to build perl.exe and
ndbgperl.exe broken on VMS. It does not address the need to have
FULLPERL = MCR PERL_ROOT:[000000]NDBGPERL.EXE
in descrip.mms files for CPAN modules built against an installed
usevmsdebug perl installation tree.
!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.
You might have built up MM_Unix.pm::init_PERL upon a flawed
(in the sense of unportable to non unified file systems OSes)
File::Spec, and as I suggested perhaps the ultimate solution should
entail the introduction of a new Configure -> config.sh -> Config.pm
variable. Could you please let this VMS specific "hack upon hack"
fix the brokeness for a minority platform under the circumstances of
a build option that is little used in practice and rarely deployed
in full? I'd prefer that the release of perl 5.8.1 not require
the kind of ad hoc post installation patching for use on VMS
that perl 5.8.0 needs.
BTW I tested my patch on a non debug build of perl on Linux
2.4.18-14smp and the tail end of a run of "make test > test.out"
appeared as:
t/x2p/s2p............................ok
All tests successful.
u=2.51 s=0.8 cu=201.83 cs=19.82 scripts=759 tests=76371
make[2]: Leaving directory `/home/pprymmer/perl_20760/perl'
make[1]: Leaving directory `/home/pprymmer/perl_20760/perl'
In particular these all came out OK:
lib/ExtUtils/t/00compile.............ok
lib/ExtUtils/t/00setup_dummy.........ok
lib/ExtUtils/t/backwards.............ok
lib/ExtUtils/t/basic.................ok
lib/ExtUtils/t/bytes.................ok
lib/ExtUtils/t/Command...............ok
lib/ExtUtils/t/Constant..............ok
lib/ExtUtils/t/Embed.................ok
lib/ExtUtils/t/hints.................ok
lib/ExtUtils/t/INST..................ok
lib/ExtUtils/t/Install...............ok
lib/ExtUtils/t/Installed.............ok
Please accept the patch. I apologize for offending
your aesthetic sensibilities regarding the code.
I too am offended. But my need for a working
debug installation outweighs my need for aesthetics.
Peter Prymmer
