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
---------------------------------
and run the "configure" script. "configure" automatically checks for
the source code in the directory that "configure" is in. For example,
- cd /usr/local/solaris/mmh
- /usr/local/src/mmh-0.1/configure
+ cd /usr/local/src/mmh # source directory
+ make clean
+ cd /usr/local/solaris/mmh # 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
reason not to use dot-locking is if the mail spool directory
is not world- or user-writeable, and thus a lock file cannot
be created.
+
+--with-lockdir=DIR
+ If you have defined "dot" locking, then the default is to
+ place the lock files in the same directory as the file that
+ is to be locked. Alternately, if you use this option, you can
+ specify that all lock files go in the specified directory.
+ Don't define this unless you know you need it.
+
+ This option is only relevant if "dot" locking is used.
+ In the other cases, it is ignored.
projects / mmh / blobdiff