]> code.delx.au - gnu-emacs/blobdiff - INSTALL
(imenu--generic-function): Use markers for positions.
[gnu-emacs] / INSTALL
diff --git a/INSTALL b/INSTALL
index a0943b6f3d073c18b4c82f060ecf3c0765e94466..522a73905438499a5088f48176b31f03f85b8757 100644 (file)
--- a/INSTALL
+++ b/INSTALL
@@ -16,8 +16,9 @@ Copyright (c) 1992, 1994 Free software Foundation, Inc.
 
 
 BUILDING AND INSTALLATION:
-(This is for a Unix or Unix-like system.  For MSDOS, see below;
-search for MSDOG.  For Windows NT, see the file nt/INSTALL.)
+
+(This is for a Unix or Unix-like system.  For MSDOS, see below; search
+for MSDOG.  For Windows NT or Windows 95, see the file nt/INSTALL.)
 
 1) Make sure your system has enough swapping space allocated to handle
 a program whose pure code is 900k bytes and whose data area is at
@@ -69,6 +70,14 @@ compile Emacs using GCC.  If you don't want to use GCC, specify
 `--with-gcc=no'.  If you omit this option, `configure' will search
 for GCC in your path, and use it if present.
 
+If you want the Emacs mail reader RMAIL to read mail from a POP
+server, you must specify `--with-pop'.  This provides support for the
+POP3 protocol; older versions are not supported.  For
+Kerberos-authenticated POP add `--with-kerberos', for Hesiod support
+add `--with-hesiod'.  These options enable Emacs to use POP; whether
+Emacs uses POP is controlled by individual users--see the Rmail
+chapter of the Emacs manual.
+
 You can build Emacs for several different machine types from a single
 source directory.  To do this, you must use a version of `make' that
 supports the `VPATH' variable, such as GNU `make'.  Make separate
@@ -510,42 +519,89 @@ problems sometimes encountered, and what to do about them.
 Installation on MSDOG (a.k.a. MSDOS)
 
 To install on MSDOG, you need to have the GNU C compiler for MSDOG
-(also known as djgpp), GNU Make, rm, mv, chmod, and sed.  See the
-remarks in config.bat for more information about locations and
-versions.
-
-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
-it.  If we find out what change introduced this requirement, we will
-try to eliminate it.  It is possible that this problem happens only
-when there is not enough physical memory on the machine.
-
-You can find out if you have a dpmi host by running go32 (part of
-djgpp) without arguments; it will tell you if it uses dpmi memory.
-For more information about dpmi memory, consult the djgpp FAQ.
-
-To build and install Emacs, type these commands:
+(also known as djgpp), GNU Make, rm, mv, and sed.  See the remarks in
+config.bat for more information about locations and versions.  The
+file etc/FAQ includes pointers to Internet sites where you can find
+the necessary utilities; search for "MS-DOS".  The configuration step
+(see below) will test for these utilities and will refuse to continue
+if any of them isn't found.
+
+If you are building the MSDOG version of Emacs on an MSDOG-like system
+which supports long file names (e.g. Windows 95), you need to make
+sure that long file names are handled consistently both when you
+unpack the distribution and compile it.  If you intend to compile with
+DJGPP v2.0 or later, and long file names support is enabled (LFN=y in
+the environment), you need to unpack Emacs distribution in a way that
+doesn't truncate the original long filenames to the DOS 8.3 namespace;
+the easiest way to do this is to use djtar program which comes with
+DJGPP, since it will note the LFN setting and behave accordingly.
+DJGPP v1 doesn't support long filenames, so you must unpack Emacs with
+a program that truncates the filenames to 8.3 naming as it extracts
+files; again, using djtar after setting LFN=n is the recommended way.
+You can build Emacs with LFN=n even if you use DJGPP v2, if some of
+your tools don't support long file names: just ensure that LFN is set
+to `n' during both unpacking and compiling.
+
+(By the time you read this, you have already unpacked the Emacs
+distribution, but if the explanations above imply that you should have
+done it differently, it's safer to delete the directory tree created
+by the unpacking program and unpack Emacs again, than to risk running
+into problems during the build process.)
+
+It is important to understand that the runtime support of long file
+names by the Emacs binary is NOT affected by the LFN setting during
+compilation; Emacs compiled with DJGPP v2.0 or later will always
+support long file names on Windows 95 no matter what was the setting
+of LFN at compile time.  However, if you compiled with LFN disabled
+and want to enable LFN support after Emacs was already built, you need
+to make sure that the support files in the lisp, etc and info
+directories are called by their original long names as found in the
+distribution.  You can do this either by renaming the files manually,
+or by extracting them from the original distribution archive with
+djtar after you set LFN=y in the environment.
+
+To unpack Emacs with djtar, type this command:
+
+    djtar -x emacs.tgz
+
+(This assumes that the Emacs distribution is called `emacs.tgz' on
+your system.)  There are a few files in the archive whose names
+collide with other files under the 8.3 DOS naming.  On native MSDOS,
+or if you have set LFN=n on Windows 95, djtar will ask you to supply
+alternate names for these files; you can just press `Enter' when this
+happens (which makes djtar skip these files) because they aren't
+required for MS-DOS.
+
+When unpacking is done, a directory called `emacs-XX.YY' will be
+created, where XX.YY is the Emacs version.  To build and install
+Emacs, chdir to that directory and 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.  The bin
+subdirectory should be added to your PATH.  The msdos subdirectory
+includes a PIF and an icon file for Emacs which you might find useful
+if you run Emacs under MS Windows.
+
+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
 work.  Synchronous subprocesses do work.
+
+The current version of djgpp 2.0 (as of August 1996) has two bugs that
+affect Emacs.  We've included corrected versions of two files from
+djgpp in the msdos subdirectory: is_exec.c and sigaction.c.  To work
+around the bugs, compile these files and link them into temacs.  The
+next version of djgpp should have these bugs fixed.