*Index of /people/ttn/software/emacs-for-vms* Name Last modified Size Description ------------------------------------------------------------------------ [DIR] Parent Directory 17-Mar-2005 06:45 - [TXT] MD5SUMS 17-Mar-2005 13:21 1k [TXT] NEWS 17-Mar-2005 13:20 1k [TXT] basis-1-synch-1.README 17-Mar-2005 13:15 1k [ ] basis-1-synch-1.diff.gz 17-Mar-2005 12:37 333k ------------------------------------------------------------------------ Welcome This dir contains a work-in-progress port of GNU Emacs to VMS. (I don't care what they call it, to me it will always be "VMS".) It is "work-in-progress" along several axes, each of which we move along a bit at at time (trying not to regress even though that can be difficult to determine w/o a proper test suite): Code Porting, Build Methodology, Installation Methodology, and GNU CVS Repository Integration. In the end, the goal is to drop as much of the idiosyncracies of the current code/methodology as possible, in the process merging all these efforts so that future development of GNU Emacs will automatically include development of GNU Emacs for VMS (assuming there is interest). A homecoming of sorts. When this goal is achieved, this directory will be archived and deleted. The zipfiles and instructions to build GNU Emacs for VMS from them thus represent a snapshot in this n-dimensional porting space and are only authoritative in the sense that someone took the time to author them, and had the decency to offer the result for distribution under the terms of the GNU GPL. Aside from the license, nothing else is guaranteed to remain unchanged. Having said that, the changes are ultimately constrained by the integration requirement that all code checked into the GNU repo must have copyright assigned to the FSF, or be very small (ten to fifteen lines last time I checked). Please keep that in mind if you wish to contribute a patch. Basis The basis for the porting work is a branch of GNU Emacs 21.2. In the following instructions, "basis-" refers to the tree you get upon invoking the command: cvs checkout -r ttn-vms-21-2-B Note that this is a unixoid shell command. Under VMS it may be similar (but I haven't checked). The CVSROOT env var should be something like ":ext:anoncvs@subversions.gnu.org:/cvsroot/emacs". Synch The "synch tree" is what you get after applying the patch. Use basis- for synch- (obvious, eh?), with command: cd emacs gunzip -c ../basis--synch-.diff.gz | patch -p1 Bootstrapping The bootstrap process involves two threads that initially start separately but come together upon invocation of CONFIGURE.COM. The first thread is creating the various DESCRIP.MMS_IN(_IN) files from the various Makefile.in files. In a sane Emacs, load file make-mms-derivative.el, change directory to the root of the synch tree, and do: M-x make-mms-derivative Makefile.in This will "parse" (har har) Makefile.in and apply edits from Makefile.in-2mms (DO NOT read this code before eating -- you may lose your appetite permanently), eventually writing out the file DESCRIP.MMS_IN in the synch tree root directory. Likewise you will need to do: M-x make-mms-derivative [.SRC]Makefile.in What's that? A VMS filename? Yes, make-mms-derivative actually can work with an already-running Emacs for VMS (if you have one available). If there are problems, try changing directory to [.SRC] first (in which case the invocation would be exactly the same as for the top-level). The second thread in bootstrapping is creating CONFIGURE.COM from CONFIGURE.COM_IN using Autoconf for VMS, available at: http://www.glug.org/people/ttn/software/autoconf-for-vms/ Make sure you use version 1.101 or later. Like the *-2mms code, CONFIGURE.COM_IN is best kept away from children and small pets, to be processed solely by the two commands: $ autoheader $ autoconf These must be done under VMS (note the DCL prompt), so at some unspecified point before and/or during the bootstrapping you will have had to transport the tree to VMS if not already. Configuration Once you have CONFIGURE.COM the best (aka "highly tested" aka "w/ highest chance for success") way to proceed is to create a parallel directory to the synch tree and build there: $ set default [-] $ create /directory [.BUILD] $ set default [.BUILD] $ @[-.EMACS]CONFIGURE - --prefix=FOO:[MY.LOCAL] - --startupdir=FOO:[MY.LOCAL.STARTUP] You may wish to use the same startupdir as for Autoconf for VMS. Build $ mmk Install To install, use the commands: $ create /directory FOO:[MY.LOCAL.STARTUP] $ mmk install Alternatively, you can run directly from the build directory, with something along the lines of: $ define uebuild FOO:[MY.BUILD.VMS] $ ue := mcr uebuild:temacs "-map" uebuild:temacs.dump Here, "ue" stands for "untrusted emacs" (since if you had trusted it, you would have installed it directly :-). Use Presently, the installation methodology requires some kind of init for each login session (can be done automatically if you have the privs) using the GNU_STARTUP.COM installed in the startupdir you specified during configuration. Run it like so: $ @FOO:[MY.LOCAL.STARTUP]GNU_STARTUP emacs-21.2 This should provide you w/ the "emacs" command, which runs a "kept editor" (the image should be interruptable via `C-z' and resumeable w/ another "emacs" invocation). Abuse You can be a silent user and suffer the bugs you encounter, or alternatively you can be a "power user" and still suffer the bugs you encounter, or alternatively you can be a "GNU Emacs on VMS conspirator" by noting the bugs you encounter (and/or create ;-) and letting me know about them in such a manner that I can reproduce and fix them or at least try to fix them. Investment If you are a flunkie who has the ear of someone in Manglement interested in the long-term viability of GNU Emacs for VMS, please encourage investment in its maintenance by way of hw/sw donation or a fixed-term maintenance/service contract. On the other hand, if you just want to leech, that's fine, too. If you are in Manglement but have no clue what this "Emacs" thingy is, ask a flunkie -- it's never too late to learn! Acknowledgements I wish to acknowledge the help of: - Mukesh Prasad, Richard Levitte and Roar Thronęs, for foundational GNU Emacs porting design and work; - the comp.os.vms denizens, for good-natured grumpiness; - Bryan Jensen, for MACRO-32 inspiration and good PHONE convos; - Ed Vogel of HP C Engineering, for explaining the difference between COMMON_BLOCK and STRICT_REFDEF extern models; - Kenichi Handa, for hints on where in the Emacs function hierarchy to best accomodate VMS I/O quirks; - FactSet Research Systems Inc., for initial funding of the port, and continued patience (since the work is not yet completed); - Richard Stallman and GNU, for FSF and Emacs and the myriad lessons these codifications of thought embody.