On Thu, Aug 21, 2003 at 09:38:37AM -0400, [EMAIL PROTECTED] wrote:
> !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.
If MakeMaker isn't finding the perl you ran Makefile.PL with then there's
a bug in find_perl() for sure.
Does PERL_ROOT:[000000]PERL.EXE exist? If so then I accuse the VMS->find_perl
"prefer relative paths" hackery. I'm pretty much convinced that resorting
should happen in init_PERL, not in find_perl, so that $^X can be left on the
front, and it should only happen if $self->{PERL_CORE}.
The attached patch implements the second part. Try applying that to
your installed ndbgperl's MM_VMS and see if it gets found.
> !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:.
Agreed. Exposed filesystem volumes suck. ;)
But regardless of this $^X should have been useful. What's it set to
in your ndbgperl.exe case?
> !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?
Yes, $Config{perlpath}. But I remember having tried using it in Test::Harness
and it causing more trouble than its worth.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-05/msg00326.html
You could try throwing $Config{perlpath} into that map... except I'm not
sure if exe_ext is already on the end or not. Not a can of worms I want
to open.
Anyhow $^X should handle this. Everything else after the check for $^X
is really desperation. I'm very curious why that's not working.
> !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.
Ok, I'm convinced now that there's a bug in find_perl() and both our
original proposed solutions would have just hacked around it.
> !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
If I have written more flawed code it is by standing on the shoulders of
Giants. ;) I blame my predecessors for the init_PERL() code.
> 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.
Now I can't accept it because I think its papering over a real bug.
Sorry, to be stubborn. Rigor and all that. Don't worry, we'll work out
something that gets your debug builds working 100%.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
Stupid am I? Stupid like a fox!
Index: lib/ExtUtils/MM_VMS.pm
===================================================================
RCS file: /usr/local/cvsroot/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm,v
retrieving revision 1.109
diff -b -u -r1.109 MM_VMS.pm
--- lib/ExtUtils/MM_VMS.pm 31 Jul 2003 03:31:25 -0000 1.109
+++ lib/ExtUtils/MM_VMS.pm 21 Aug 2003 19:36:58 -0000
@@ -164,6 +164,8 @@
my($rslt);
my($inabs) = 0;
local *TCF;
+
+ if( $self->{PERL_CORE} ) {
# Check in relative directories first, so we pick up the current
# version of Perl if we're running MakeMaker as part of the main build.
@sdirs = sort { my($absa) = $self->file_name_is_absolute($a);
@@ -183,6 +185,12 @@
else { $bb =~ /\d/ <=> $ba =~ /\d/
or substr($ba,0,1) cmp substr($bb,0,1)
or length($bb) <=> length($ba) } } @$names;
+ }
+ else {
+ @sdirs = @$dirs;
+ @snames = @$names;
+ }
+
# Image names containing Perl version use '_' instead of '.' under VMS
foreach $name (@snames) { $name =~ s/\.(\d+)$/_$1/; }
if ($trace >= 2){
