either edit the Makefile by hand, using Descrip.MMS as a guide, or use the
Makefile to build Miniperl.Exe, and then run the Perl script MMS2Make.pl,
found in the [.VMS] subdirectory, to generate a new Makefile with the options
-appropriate to your site. If you are using MM[SK], and you decide to rebuild
-Perl with a different set of parameters (e.g. changing the C compiler, or
-adding socket support), be sure to say
+appropriate to your site.
+
+If you are using MM[SK], and you decide to rebuild Perl with a different set
+of parameters (e.g. changing the C compiler, or adding socket support), be
+sure to say
$ MMK/Descrip=[.VMS] realclean
first, in order to remove files generated during the previous build. If
you omit this step, you risk ending up with a copy of Perl which
composed partially of old files and partially of new ones, which may lead
to strange effects when you try to run Perl.
-Note for sites using DECC: A bug in some early versions of the DECC RTL on the
-AXP causes newlines to be lost when writing to a pipe. This causes
-Gen_ShrFls.pl to fail, since it can't read the preprocessor output to identify
-global variables and routines. A different bug in the DECC preprocessor itself
-for some patched versions of DECC 4.0 on the VAX also makes it impossible for
-Gen_ShrFls.pl to parse the preprocessor output. In either case, the problem is
-generally manifested as missing global symbols when linking PerlShr.Exe or
-Perl.Exe. You can work around this problem by defining the macro
-DECC_PIPES_BROKEN when you invoke MMS or MMK.
+A bug in some early versions of the DECC RTL on the AXP causes newlines
+to be lost when writing to a pipe. A different bug in some patched versions
+of DECC 4.0 for VAX can also scramble preprocessor output. Finally, gcc 2.7.2
+has yet another preprocessor bug, which causes line breaks to be inserted
+into the output at inopportune times. Each of these bugs causes Gen_ShrFls.pl
+to fail, since it can't parse the preprocessor output to identify global
+variables and routines. This problem is generally manifested as missing
+global symbols when linking PerlShr.Exe or Perl.Exe. You can work around
+it by defining the macro PIPES_BROKEN when you invoke MMS or MMK.
+
This will build the following files:
Miniperl.Exe - a stand-alone version of without any extensions.
h2xs - Perl program which generates template files for creating
XSUB extensions, optionally beginning with the #defined
constants in a C header file.
- [.pod]perldoc - A Perl program which locates and displays documentation
+ [.lib.pod]perldoc - A Perl program which locates and displays documentation
for Perl and its extensions.
[.Lib]Config.pm - the Perl extension which saves configuration information
about Perl and your system.
Once the build is complete, you'll need to do the following:
- Put PerlShr.Exe in a common directory, and make it world-readable.
If you place it in a location other than Sys$Share, you'll need to
- define the logical name PerlShr to point to the image.
+ define the logical name PerlShr to point to the image. (If you're
+ installing on a VMScluster, be sure that each node is using the
+ copy of PerlShr you expect [e.g. if you put PerlShr.Exe in Sys$Share,
+ do they all share Sys$Share?]).
- Put Perl.Exe in a common directory, and make it world-executable.
- Define a foreign command to invoke Perl, using a statement like
$ Perl == "$dev:[dir]Perl.Exe"
* For more information
-If you're interested in more information on Perl in general, consult the Usenet
-newsgroups comp.lang.perl.announce and comp.lang.perl.misc. The FAQ for these
-groups provides pointers to other online sources of information, as well as
-books describing Perl in depth.
+If you're interested in more information on Perl in general, you may wish to
+consult the Usenet newsgroups comp.lang.perl.announce and comp.lang.perl.misc.
+The FAQ for these groups provides pointers to other online sources of
+information, as well as books describing Perl in depth.
If you're interested in up-to-date information on Perl development and
internals, you might want to subscribe to the perl5-porters mailing list. You
can do this by sending a message to perl5-porters-request@nicoh.com, containing
the single line
subscribe perl5-porters
-This is a moderately high-volume list at the moment (25-50 messages/day).
+This is a high-volume list at the moment (>50 messages/day).
If you're interested in ongoing information about the VMS port, you can
-subscribe to the VMSperl mailing list by sending a request to
-bailey@genetics.upenn.edu (it's to a human, not a list server - this is a small
-operation at the moment). And, as always, we welcome any help or code you'd
+subscribe to the VMSPerl mailing list by sending a request to
+vmsperl-request@genetics.upenn.edu, containing the single line
+subscribe VMSPerl
+as the body of the message. And, as always, we welcome any help or code you'd
like to offer - you can send mail to bailey@genetics.upenn.edu or directly to
-the VMSperl list at vmsperl@genetics.upenn.edu.
+the VMSPerl list at vmsperl@genetics.upenn.edu.
Finally, if you'd like to try out the latest changes to VMS Perl, you can
retrieve a test distribution kit by anonymous ftp from genetics.upenn.edu, in
for the getredirection() code
Rich Salz <rsalz@bbn.com>
for readdir() and related routines
- Denis Haskin <DWH@epub.ziff.com>
- for work on a pod-to-hlp translator for the Perl documentation
- Richard Dyson <dyson@blaze.physics.uiowa.edu> and
- Kent Covert <kacovert@miavx1.acs.muohio.edu>
- for additional testing on the AXP.
+ Peter Prymmer <pvhp@lns62.lns.cornell.edu)
+ for extensive testing, as well as development work on
+ configuration and documentation for VMS Perl,
+ the Stanford Synchrotron Radiation Laboratory and the
+ Laboratory of Nuclear Studies at Cornell University for
+ the the opportunity to test and develop for the AXP,
and to the entire VMSperl group for useful advice and suggestions. In addition
the perl5-porters, especially Andy Dougherty <doughera@lafcol.lafayette.edu>
and Tim Bunce <Tim.Bunce@ig.co.uk>, deserve credit for their creativity and
willingness to work with the VMS newcomers. Finally, the greatest debt of
-gratitude is due to Larry Wall <lwall@sems.com>, for having the ideas which
+gratitude is due to Larry Wall <larry@wall.org>, for having the ideas which
have made our sleepless nights possible.
Thanks,