summaryrefslogtreecommitdiff
path: root/INSTALL
diff options
context:
space:
mode:
authorRichard M. Stallman <rms@gnu.org>1996-04-17 16:43:16 +0000
committerRichard M. Stallman <rms@gnu.org>1996-04-17 16:43:16 +0000
commitdb50afc09f10adb8bb0f7d0ec6a2ec1f9c439410 (patch)
tree966fa79e36d4b275f57682efff1b2f4f1097627e /INSTALL
parent95184b48ec94a4def68e8a0123afa1623a088d2f (diff)
downloademacs-db50afc09f10adb8bb0f7d0ec6a2ec1f9c439410.tar.gz
Clarify MSDOS installing and unpacking.
Diffstat (limited to 'INSTALL')
-rw-r--r--INSTALL40
1 files changed, 19 insertions, 21 deletions
diff --git a/INSTALL b/INSTALL
index de4042b1c6b..728d2394a25 100644
--- a/INSTALL
+++ b/INSTALL
@@ -517,11 +517,12 @@ versions.
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 @@ To build and install Emacs, type these commands:
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.
-
-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.
+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.
+
+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