Michael G Schwern wrote:
On Fri, Jul 15, 2005 at 12:49:01AM -0400, John E. Malmberg wrote:
Ya know, if there's this many differences between your flavor of VMS
and the more traditional flavor rather than trying to wedge them both
into File::Spec::VMS and MM_VMS you should probably make a new
subclass. File::Spec::VMS::Unix or something.
Unfortunately making such a change is beyond my skill set. I do not
know how to make such a modification to Perl.
Unless a white knight comes in to clean this all up, I can't see how it could
be applied to the mainline. :(
Step 1: Make a version work. What you (and the others on the vmsperl
list) have seen is actually the tip of the iceberg. Small stuff.
The real big changes are in vms.c. And I have not posted them yet.
That will happen sometime today.
Step 2: Optimize and merge into main line. That requires discussion,
and discussion requires that the participants look at the changes and
give feedback.
I now have information that allows me to optimize the perl scripts. My
knowledge of Perl scripting while still elementary is far better than
what it was when I started hacking the Perl scripts. And I now know
what global switches that I need.
I also have to go through now and audit all the 'VMS' specific code in
the Perl tests, and remove the skips for things that VMS can do with my
variant, and also remove more VMS specific code that I have discovered
did not need to be there before my modifications, and only breaks
running on VMS in UNIX emulation.
Actually it is not "what sort of VMS am I on?" but how has VMS been told
to behave for this running of Perl.
You're running smack into a flawed assumption throughout much Perl code
which trying to nail down things about the operating environment based
solely on $^O. Breaking that assumption opens a barrel of worms. Its
a barrel that needs to be opened, just letting you know what you're getting
into.
Closing barrels of worms seems to have become a career specialty,
especially ones that I did not open. So ones that I open are usually
not as big as a problem.
You're right, MakeMaker currently cannot output anything but MMS/K on VMS.
As far as its concerned when $^O eq 'VMS' you're using MMS/K. And when
$^O eq 'MSWin32' you're using nmake or dmake. This is a deep assumption in
the code. Breaking this assumption will require a whole lot more code
change than I'd like, MakeMaker is very fragile and time consuming to test.
Yes, I know because I made it work in two new modes on VMS. Maybe not
the way that you wanted, but I made it work.
That said, its something I've been wanting to do for a long time but it
has a high probability of breaking existing code and will be an enormous
time suck.
As I optimize, I might be able to simplify things.
VMS shell program name commands issued through Perl do not need an MCR
in front of them if they have a pathname component, including './' on
them. That is true in the CPAN version of Perl. So in most cases the
'MCR' is not needed.
The ' : ' is an MMS/MMK specific issue, not a VMS specific one.
I have not tried this yet, but I should be able to get Perl on VMS to
build with the CRTL in UNIX REPORT mode, which is available all versions
of VMS that I see people on this list reporting testing the current
version of Perl on, so it means that my changes should work on them.
The impact of that working is that there are only a few VMSism that
MAKEMAKER really has to deal with. The ones that I have discovered are:
1. In UNIX mode, ODS-2 names are in uppercase as that is their native
value. It is a VMS perlism that is lowercasing all VMS filenames before
it passes them to the scripts and extensions. So on VMS case
insensitive filename compares are needed to run on both filesystems.
I need to fix anything in Perl that assumes $^O of 'VMS' means lowercase
filenames for this reason, as the file could come back in upper/lower/or
exact if the script is expected to run on VMS.
2. ODS-2 has a restricted character set, which means only one dot for
filenames, and none in directory names.
And I saw an issue about MMS/MMK not handling shell environment
variables correctly. I need to find out more about that.
If I am right, I think that the issue is different what has been tried
to be worked around.
You see on VMS there are three name spaces that are read by a getenv() call.
1. Internal environment table.
2. The DCL symbol table.
3. A set of logical name tables.
It seems that the implementation of Perl on VMS is mapping the %ENV{}
function to the VMS logical name tables when you set them.
MMS/MMK can only read environment values from the DCL symbol table.
So it is not an issue about MMS/MMK being broken, it is that setting the
%ENV{foo}=bar is creating a logical name 'foo' instead of the DCL symbol
'foo' that is needed. And that may be a small can of worms to figure
out how to fix.
In VMS, the DCL symbols are used by the shell, and the logical names are
used by the file system.
What I may need is a mode to tell Perl on VMS where to create new
environment variables, and on VMS makemaker would need to set it. Then
all the macro expansion stuff is in the VMS filehandling would not be
needed for makemaker, and probably not needed anywhere else.
So from the VMS folks, anyone familiar enough with how the %ENV is
handled to give me some hints?
-John
[EMAIL PROTECTED]
Personal Opinion Only
