changeset 15039:43c846d45f79

Clarify MSDOS installing and unpacking.
author Richard M. Stallman <rms@gnu.org>
date Wed, 17 Apr 1996 16:43:16 +0000
parents 2376256a0204
children 04f81516b6e0
files INSTALL
diffstat 1 files changed, 18 insertions(+), 20 deletions(-) [+]
line wrap: on
line diff
--- a/INSTALL	Tue Apr 16 23:07:52 1996 +0000
+++ b/INSTALL	Wed Apr 17 16:43:16 1996 +0000
@@ -517,11 +517,12 @@
 If you are compiling on an MSDOG-like system which has long file
 names, you may need to do `SET LFN=y' for some of the commands,
 especially the compilation commands.  It might be more convenient to
-unpack the Emacs distribution with djtar, which comes with djgpp;
-djtar truncates file names to 8.3 naming as it extracts files, even if
-the system allows long file names, and this ensures that build
-procedures designed for 8.3 file names still work.  Use as in `djtar x
-foo.tar' or `djtar x foo.tgz'.
+unpack the Emacs distribution with djtar, which comes with djgpp; if
+you do `SET LFN=n' before unpacking, djtar truncates file names to 8.3
+naming as it extracts files, even if the system allows long file
+names, and this ensures that build procedures designed for 8.3 file
+names still work.  Use djtar with the command `djtar -x foo.tar' or
+`djtar -x foo.tgz'.
 
 Some users report that running Emacs 19.29 requires dpmi memory
 management.  We do not know why this is so, since 19.28 did not need
@@ -541,22 +542,19 @@
     config msdos
     make install
 
-You may need to work around a type conflict between gmalloc.c and the
-header file djgppstd.h regarding declarations of memalign and valloc.
-Temporarily deleting those declarations from djgppstd.h while compiling
-Emacs or while compiling gmalloc.c should do it.  We found out about this
-problem too late to include a more convenient fix--sorry.
+Building Emacs creates executable files in the src and lib-src
+directories.  Installing Emacs on MSDOS moves these executables to a
+sibling directory called bin.  For example, if you build in directory
+/emacs, installing moves the executables from /emacs/src and
+/emacs/lib-src to the directory /emacs/bin, so you can then delete the
+subdirectories /emacs/src and /emacs/lib-src if you wish.  The only
+subdirectories you need to keep are bin, lisp, etc and info.
 
-To save disk space, Emacs is built with the idea that you will execute
-it from the same place in the file system where you built it.  As the
-/usr/local/ subtree does not exist on most MSDOG systems, the
-executables might be placed in /emacs/bin/, for instance, in which
-case there should also be /emacs/lisp, /emacs/info and /emacs/etc
-directories.  In general, with the default path handling, the etc/,
-info/ and lisp/ directories are expected to exist in ../ relative to
-the directory containing the executing binary.  This behaviour can be
-overridden by setting the HOME environment variable to the directory
-containing lisp/ etc.
+Emacs on MSDOS finds the lisp, etc and info directories by looking in
+../lisp, ../etc and ../info, starting from the directory where the
+Emacs executable was run from.  You can override this by setting the
+environment variable HOME; if you do that, the directories lisp, etc
+and info are accessed as subdirectories of the HOME directory.
 
 MSDOG is a not a multitasking operating system, so Emacs features such
 as asynchronous subprocesses that depend on multitasking will not