Mercurial > emacs
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