Michael G Schwern wrote:
On Thu, Jul 14, 2005 at 12:03:01PM -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.
And only a very small number of changes are really needed for my new
flavor of VMS.
Most of the changes are to make Perl on VMS not break when features that
have been in the operating system for a while are enabled. These
features are documented in the version 7.2 manual dated February 2002,
and many of them were around before that.
Michael G Schwern wrote:
On Thu, Jul 14, 2005 at 05:38:53PM -0400, John E. Malmberg wrote:
ExtUtils::MakeMaker is available as a separate CPAN module. Please
patch against that as it is more up to date and easier to figure out
if the bug is in Perl or MakeMaker.
The up-to-the-moment version is available from
http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk
Once this stuff gets through the peer review process for the people like
Craig Berry and such who understand the Perl coding practices, then that
would probably be the thing to do.
These changes should be at most harmless until the rest of the VMS
Perl catches up with them, or at worse, Perl really does not
function well if you put the CRTL in the UNIX modes now.
Before I even jump into this code I have to protest at the size of
it. I've spent years whittling down and encapsulating all the special
cases in MakeMaker, particularly for VMS, and now this adds a ton.
MakeMaker is a special case because it is needed for building of Perl
and for embedded applications. Because of that it needs to be able to
run in all VMS modes, but at this time the UNIX emulation
I think part of the problem is the repetition. I see this sort of
thing repeated a lot.
+if ($Is_VMS) {
+ my $unix_report;
+ my $unix_only;
+
+ $unix_report = $ENV{'DECC$FILENAME_UNIX_REPORT'};
+ if (defined $unix_report) {
+ if (($unix_report lt '1') && ($unix_report ne 'ENABLE')) {
+ $unix_report = undef;
+ }
+ }
+ $unix_only = $ENV{'DECC$FILENAME_UNIX_ONLY'};
+ if (defined $unix_only) {
+ if (($unix_only lt '1') && ($unix_only ne 'ENABLE')) {
+ $unix_only = undef;
+ }
+ }
+ $unix_report = 1 if (defined $unix_only);
I totally agree, but simplifying it is currently beyond my Perl coding
skills.
Six months ago, I was bliss fully ignorant of doing any perl coding.
Now, while I have learned some elementary Perl programming skills, I
have learned quite a bit about debugging Perl modules and extensions.
Not only in this patch but in many of the other patches you've
submitted. I think step one of your porting effort should be to
encapsulate this "what sort of VMS am I on?" logic into a module.
Perhaps something as simple as a bunch of new File::Spec::VMS
methods.
Actually it is not "what sort of VMS am I on?" but how has VMS been told
to behave for this running of Perl.
There are at least three different controls for the of handling
traditional VMS file specifications by the CRTL. Before my changes,
Perl could only deal with a subset of VMS file specifications.
These interact with about 7 different controls for the handling of UNIX
filenames by the CRTL. Essentially there are at least 36 different ways
a UNIX filename could be interpreted before this mode that a future VMS
version will add.
I was considering doing something like that, but until I got all the
tests to actually pass, I did not know what options would be needed, and
then I would have to learn how to implement the new methods.
And then there is an issue of should it be one method with many
properties, or many methods.
So I'd recommend you halt your porting and focus on encapsulating the
differences between your VMS environment and the traditional one. I
doubt your patches will be accepted in their current state and I'd
hate to see all that effort wasted.
Not practical. And the effort is not wasted. In any case, it is
basically done for 5.8.6, and if I can get 5.8.7 done quickly, all the
better.
I need a working Perl of a reasonably recent vintage that understands
VMS operating in a mode where it is pretending to be UNIX for several
projects.
It is a case where a step in those projects have perl scripts that
assume that they are running on UNIX, and modifying the scripts is not
practical because the people maintaining the scripts do not have VMS
knowledge.
So a Perl is needed that can pretend it is UNIX on VMS. It is ok for it
to still report it is VMS because these scripts don't seem to check for
that.
The 5.8.6 version with those mods are in QTV testing now. This is also
giving the new pre-release VMS CRTL a work out, as the Perl test scripts
are one of the first real programs to exercise the new features. As
5.8.7 is only slightly different than 5.8.7, if I can quickly merge
those changes in, I will hopefully have a better custom release than 5.8.6.
Getting the MAKEMAKER stuff to run in all three modes has also exposed
bugs in corner cases of my changes to VMS.C
Modules that are not a part of the Perl self tests will not likely need
to run in all three modes.
The two new modes are for running UNIX Perl scripts that have not yet
been ported to VMS, and is intended to eliminate changing the scripts to
run them on VMS.
As I stated before, Makemaker is probably an exception as since it is in
the test scripts, I change my copy so that it would run in all three
modes. But the changes are keyed off of OS type of VMS.
Craig A. Berry wrote:
: These aren't the only reasons we need a different way to test CRTL
: features from Perl. The assumption in the code as written is that
: the %ENV hash maps to logical names, which may or may not be the
: case. We probably need some XS to really do this right, something
: comparable to VMS::Filespec that is wired into the core and available
: everywhere, even in miniperl. I'm thinking of something like
: VMS::CRTL->feature_get() and VMS::CRTL->feature_set() as wrappers
: around the C calls that query and set the C run-time features.
Actually because the support of these features has been missing for some
time, there are no VMS perl scripts other than what is packaged with
Perl that are dependent on all the many features.
So these can be subset into these main modes:
1. Traditional VMS behavior.
2. Enhanced VMS/UNIX Behavior with file names
reported in traditional VMS mode.
3. Enhanced VMS/UNIX behavior with file names
reported in UNIX mode.
4. Enhanced VMS/POSIX mode with file names reported
in UNIX mode for future VMS version.
Room should be left for expansion, such as an all POSIX file
specification mode, or an all VMS mode, but those would require such a
radical change to Perl, I doubt that they would happen, especially an
all VMS mode.
Getting this issue decided will drive how I would do any future updates.
>I doubt your patches will be accepted in their current state and I'd
> hate to see all that effort wasted.
:
: The hard link and symlink support are probably close to ready for
: prime time. But a VMS mutant that expects, requires and reports file
: names in Unix syntax is really quite a different beast than anything
: the VMS port of Perl has dealt with in the past, ...
Effectively support of symbolic links requires that Mutant. As stated
above, there is a strong need for that Mutant to exist now. That is one
of the main reasons that I have been doing so much work.
And you already have a partially hidden issue. Installing GNV or any
other product that defines a logical name SYS$POSIX_ROOT causes a
significant change in the behavior of the CRTL that the existing Perl
for VMS does not know how to correctly deal with unless you define a
feature logical. In most cases this is harmless.
: and may call for more of a paradigm shift than patching the tests
: one at a time.
If you look at the patches for the test scripts, many of them are to
make them work in VMS mode with ODS-5 file specifications, and quite a
few of them are for removing VMS specific code because VMS.C already
handled the UNIX variant. It is just that implementing the UNIX modes
exposed that there was unneeded VMS specific code that only prevented
VMS from working in the UNIX mode.
In many cases it is just turning off the VMS specific behavior when UNIX
modes are active.
MakeMaker is a special case, because MMK/MMS effectively require VMS
file specifications, and the tests expect to see them.
: If Configure could be made to run within GNV, and if $^O could report
: something other than 'VMS', we might be closer to what is really
: needed.
Careful of what you ask for. :-) The main missing piece seems to be
that a template is missing for GNU MAKE, and that MakeMaker needs to
know that for that flavor of VMS it needs to make sure that all the
filenames are in UNIX format. Of course the Mutant variant that I have
now will give it the names that way.
And remember I asked how to do that already before I started on the path
I went. If I could have done that method faster, I would have. But
from what I could see, at least the same amount of work would have been
needed.
Since I do not think that MakeMaker can generate anything other than
MMK/MMS files on VMS right now, as IIRC, I saw that the description file
name was driven by the $^O and not by the make program name in at least
one place.
Now with the version of Perl that can run with UNIX emulation mode, all
MakeMaker needs to know that if the make program is MMK or MMS it should
output the files in VMS format, but be prepared that filenames could be
returned in UNIX or VMS format.
But when outputting to other make programs it could assume that it would
be supplied all the file names in UNIX format and not need VMS specific
actions at all.
The issue with MMK/MMS is that a description file must have it's
dependencies in all VMS or all UNIX format. I think when the C compiler
is run from MMS/MMK, it can accept UNIX file specifications.
So the simplification for MakeMaker might be to put the CRTL in UNIX
mode, and
: Nevertheless, I think John's work is an important proof of
: concept and may turn out to be the direction we ultimately follow. I
: do wish I had more time to delve into all of this as I think it will
: need some kicking about before we can say we are ready to get it
: checked in to the repository.
While you are kicking it around, I have to get this tested and out for
the projects that need it on VMS, so I will not be able to wait.
The last thing I want to do is to be a maintainer of a custom variant of
Perl, but this functionality is needed as of last year, and I got tapped
to get it done.
But consider this, with a Perl on VMS that pretends it is UNIX, how many
more Perl applications will now be available for it with no porting effort?
-John
[EMAIL PROTECTED]
Personal Opinion Only
