Please read all of the following instructions before you begin
building mmh.
-You should check the docs/MACHINES file to see if there are any
-specific build instructions for your operating system. To build mmh,
-you will need an ANSI C compiler such as gcc.
+Mmh can be built and installed on POSIX-compliant systems, using
+an ANSI C compiler. (Check out docs/MACHINES for shortcomings of
+operating systems.)
0) If you have obtained mmh by checking it out of the version control
system, you will need to run the GNU autotools to regenerate some
./autogen.sh
- (Note that if you're doing mmh development, you should look at
+ (If you're doing mmh development, you should look at
docs/README.developers for related information.)
1) From the top-level source directory, run the command:
./configure [options]
- This will check the configuration of your OS, as well as the various
- Makefiles.
+ This will check the configuration of your OS, as well as generate
+ the various Makefiles.
The configure script accepts various options. The options of
most interest are listed in a section below. To see the list
2) make
+ For less terminal output, use: make -s
+
3) make install
Note that if you have mmh files in the target directories with
existing file. Watch for information messages while make is processing
that directory to see if you need to merge changes.
-4) You may edit the file `mhn.defaults' in the mmh `etc' directory.
+4) You may edit the file `mhn.defaults' in mmh's `etc' directory.
This file contains the default profile entries for the mmh commands
mhlist/mhstore/show. The syntax of this file is described in section
5) Add the bindir to your PATH variable.
- If you haven't change any paths, then the bindir is `/usr/local/mmh/bin'.
- Likely, your PATH is set in ~/.profile, ~/.kshrc, ~/.bashrc, or a similar
- file. Have a look at mmhwrap(1), which allows you to access mmh tools
+ If you haven't changed any paths, then the bindir is
+ `/usr/local/mmh/bin'. Adjust your PATH in ~/.profile, ~/.kshrc,
+ ~/.bashrc, or a similar file.
+
+ Have a look at mmhwrap(1), which allows you to access mmh tools
conveniently without changing the PATH variable.
If you want to add to, not replace, compile flags, you can use OURDEFS:
./configure OURDEFS='-Wextra -Wno-sign-compare'
-----------------------------------------
-Building mmh on additional architectures
-----------------------------------------
-To build mmh on additional architectures, you can do a "make distclean".
-This should restore the mmh source distribution back to its original
-state. You can then configure mmh as above on other architectures in
-which you wish to build mmh. Or alternatively, you can use a different
-build directory for each architecture.
-
---------------------------------
Using a different build directory
---------------------------------
/usr/local/src/mmh/configure
make
+----------------------------------------
+Building mmh on additional architectures
+----------------------------------------
+To build mmh on additional architectures, you can do a "make distclean".
+This should restore the mmh source distribution back to its original
+state. You can then configure mmh as above on other architectures in
+which you wish to build mmh. Or alternatively, you can use a different
+build directory for each architecture.
+
---------------------
Options for configure
---------------------
They are seldom useful to normal users.
--sysconfdir=DIR (DEFAULT is ${prefix}/etc)
- mmh's config files (mhn.defaults, ...) are installed here.
+ mmh's global config files (mhn.defaults, ...) are installed here.
--mandir=DIR (DEFAULT is ${prefix}/man)
mmh's man pages are installed here.
--enable-debug
- Enable debugging support.
+ Add debugging symbols to the binaries.
--with-locking=LOCKTYPE (DEFAULT is dot)
Specify the locking mechanism when attempting to "inc"
a local mail spool. Valid options are "dot", "fcntl", "flock",
- and "lockf". Of the four, dot-locking requires no special kernel
+ and "lockf".
+
+ Of the four, dot-locking requires no special kernel
or filesystem support, and simply creates a file called
"FILE.lock" to indicate that "FILE" is locked.
+ If LOCKDIR is specified, lock files will be created in that
+ directory. Otherwise, lock files will be created in the
+ directory where the file being locked resides.
+
+ To configure nmh for kernel locking, use one of the `flock',
+ `lockf' or `fcntl' values, each using the equally named
+ system call to perform the kernel-level locking.
In order to be effective, you should contact the site
administrator to find out what locking mechanisms other
Mmh is a modified version of the electronic mail handling system nmh.
Nmh (new MH) itself was originally based on the package MH-6.8.3, and
was intended to be a (mostly) compatible drop-in replacement for MH.
-In contrast, mmh is not inteded to be a drop-in replacement for nmh,
+In contrast, mmh is not intended to be a drop-in replacement for nmh,
rather mmh breaks compatibility to nmh in order to modernize and
simplify it.
-Mmh is young and small; nmh is established and matured; MH is ancient.
+Mmh is small and simple; nmh is established and matured; MH is ancient.
-This distribution uses the term ``nmh'' to describe something common
-to nmh and mmh, in order to give credit. Where mmh differs much from
-nmh, the term ``mmh'' is used to avoid confusing the user.
-Unfortunately, the terms are not used fully consistent.
+Unfortunately, the usage of the terms `mmh' and `nmh' is not fully
+consistent within the distribution.
Installing
----------
-Please read the INSTALL file.
+See the INSTALL file.
Copying
-------
-Mmh uses a BSD-style license, which should be in the top-level of the
-distribution in a file named COPYRIGHT.
+Mmh uses a BSD-style license, which can be found in the COPYRIGHT
+file.
Users
-----
-Start with reading the man page mmh-intro(7). It explains the first
+Start by reading the man page mmh-intro(7). It explains the first
steps. For convenience in the shell, have a look at the files
docs/COMPLETION-*. They give cookbook examples of how to set up mmh-
specific tab completion in your shell.
README.developers file in the docs subdirectory of this distribution.
Markus Schnalke's master's thesis explains the existence, shape, and
focus of mmh. You should read it before working on mmh. If you're
-hacking on the code, you should subscribe to the nmh-workers mailing
-list. To do so, please visit the nmh-workers info page at
-<http://lists.nongnu.org/mailman/listinfo/nmh-workers>. Up to now,
-mmh has no separate mailing list.
+hacking on the code, you should subscribe to mmh's mailing list. To
+do so, send a message to <mmh-request@marmaro.de> with the subject
+``subscribe''.
Bug reports
-----------
-Please send bug reports and suggestions to either Markus Schnalke
-<meillo@marmaro.de> or to the <nmh-workers@nongnu.org> mailing list.
+Please send bug reports and suggestions to the mailing list:
+<mmh@marmaro.de>.
Acknowledgments
---------------
-The MH system was originally developed in 1979 by the RAND
-Corporation. It was written primarily by Bruce S. Borden after ideas
-in a memo by R. Stockton Gaines and Norman Z. Shapiro. In 1982,
-the University of California, Irvine took up maintenance of the
-software, under the direction of Marshall T. Rose and John L. Romine.
-
-nmh was started by Richard Coleman (coleman@math.gatech.edu) after
+The MH system was originally developed by the RAND Corporation,
+starting in 1979. It was written mainly by Bruce S. Borden after
+ideas in a memo by R. Stockton Gaines and Norman Z. Shapiro. In
+1982, the University of California, Irvine took up maintenance of
+the software, under the direction of Marshall T. Rose and John L.
+Romine.
+
+Nmh was started by Richard Coleman (coleman@math.gatech.edu) after
development on MH mostly stopped. He did the original autoconfiscation
-and most of the other work up until version 1.0. nmh is currently being
+and most of the other work up until version 1.0. Nmh is currently being
developed and maintained by a loosely organized group of volunteers.
-For more information
---------------------
-There is more information in the docs subdirectory. Please note that
-several documents are historic.
+More information
+----------------
+There is more information in the docs subdirectory. Some of the
+documents are historic, however.
The mmh website is located at <http://marmaro.de/prog/mmh/>.
Feel free to contact Markus Schnalke <meillo@marmaro.de>.
# MACHINE -- operating system specific information
#
-nmh is known to compile on the following platforms (save the
-exceptions noted below), using an ANSI C compiler, such as gcc.
-
-AIX 4.1.5.0.01
-FreeBSD
-IRIX 6.5
-Linux 2.2, 2.3, 2.4 (glibc 2.1, glibc 2.2)
-Mac OS X Public Beta
-NetBSD 1.4.2
-OpenBSD
-Solaris 7 and 8 (sparc,x86)
-SunOS 4.1
-
-Known Compilation problems:
---------------------------------------
-FreeBSD:
-OpenBSD:
-NetBSD:
-
-Some BSD4.4 machines have problems when running nmh's configure script.
-They will be unable to find the location of vi and sendmail. This is
-due to POSIX features (breakage?) in the shell sh. The solution is to
-run the configure script under the shell `bash':
-
- % bash configure
-
---------------------------------------
-Mac OS X/Rhapsody 5:
-
-Version 5.3 at least has the same sh/bash bug as the *BSD systems
-above. This appears to be fixed in 5.5.
-
-Will not compile correctly unless you configure with the --enable-debug
-option. It appears to find conflicts in the headers only when debugging
-is disabled. With debugging enabled, it compiles and runs happily.
-
---------------------------------------
-HPUX:
-
-Lots of problems have been reported with using HPUX `cc'. In particular,
-problems with `scan' giving incorrect dates (everything is 01/00).
-It is highly recommended that you use `gcc' instead.
-
-Also, new versions of HPUX (10.20?) will core dump in `scan' because
-of some workaround code in zotnet/tws/lexstring.c. This workaround is
-needed for older versions of HPUX, but causes problems on newer versions.
-The solution is the added line (minus our indentation):
-
- #undef hpux
-
-after line 15 of the file zotnet/tws/lexstring.c.
-
---------------------------------------
-Irix (SGI):
-
-Irix make is notoriously buggy. If you're using it, you should "touch
-config.h.in" before configuring to prevent a problem where it tries to
-rebuild targets that shouldn't be rebuilt. (Alternately, you can just
-use GNU make instead of Irix make.)
-
---------------------------------------
-Linux:
-
-The configuration script does a test to discover if your vi is broken
-(if it reports non-zero exit codes on certain pseudo-errors). This test
-will hang if the program `ex' on your system is a link to the vi clone
-`vile'. The workaround is to replace the command ex as a link to another
-vi clone such as nvi or elvis.
-
---------------------------------------
-Solaris:
-
-With --enable-debug you'll see a lot of warnings. This is even worse
-when compiling using the Sun Workshop compiler since it issues a
-warning for every instance of a problem instead of summarizing them.
-The main one concerns arrays with an index of type char. This is ok.
-The array itself is a hash of chars, so the array size and the type
-match. There isn't another safe and portable way to do this at the
-moment. An explicit cast would get rid of the warnings, but I think
-it's better to leave it complaining for now until we come up with
-a better solution. The whole thing is probablly going to be chucked
-with UTF-8 support anyway.
-
-Other than the warnings, it builds ok.
---------------------------------------
-SunOS 4.1.1/4.1.3/4.1.4:
-
-You can't use the C compiler that comes with SunOS 4 since
-it isn't ANSI C. But nmh builds just fine with gcc. With
---enable-debug you will see a lot of warnings.
---------------------------------------
-
+Mmh can currently not be built with musl-libc. The reason is that
+m_getfld() makes use of stdio internals. This is going to be fixed.
projects / mmh / commitdiff