version 1.1, 2014/08/08 16:45:39 |
version 1.8, 2014/12/09 12:05:44 |
|
|
$Id$ |
$Id$ |
|
|
Installing mdocml, the portable mandoc distribution |
About mdocml, the portable mandoc distribution |
--------------------------------------------------- |
---------------------------------------------- |
|
|
The mandoc manpage compiler toolset is a suite of tools compiling |
The mandoc manpage compiler toolset is a suite of tools compiling |
mdoc(7), the roff(7) macro language of choice for BSD manual pages, |
mdoc(7), the roff(7) macro language of choice for BSD manual pages, |
and man(7), the predominant historical language for UNIX manuals. |
and man(7), the predominant historical language for UNIX manuals. |
For general information, see: http://mdocml.bsd.lv/ |
Since the present version 1.13.2, it includes a man(1) manual viewer |
|
in addition to the apropos(1) manual page search tool. |
|
For general information, see <http://mdocml.bsd.lv/>. |
|
|
|
In this document, we describe the installation and deployment of |
|
mandoc(1), first as a simple, standalone formatter, and then as part of |
|
the man(1) system. |
|
|
|
In case you have questions or want to provide feedback, read |
|
<http://mdocml.bsd.lv/contact.html>. Consider subscribing to the |
|
discuss@ mailing list mentioned on that page. If you intend to |
|
help with the development of mandoc, consider subscribing to the |
|
tech@ mailing list, too. |
|
|
|
Enjoy using the mandoc toolset! |
|
|
|
Ingo Schwarze, Karlsruhe, December 2014 |
|
|
|
|
|
Installation |
|
------------ |
Before manually installing mandoc on your system, please check |
Before manually installing mandoc on your system, please check |
whether the newest version of mandoc is already installed by default |
whether the newest version of mandoc is already installed by default |
or available via a binary package or a ports system. A list of the |
or available via a binary package or a ports system. A list of the |
latest bundled and ported versions of mandoc for various operating |
latest bundled and ported versions of mandoc for various operating |
systems is maintained at: http://mdocml.bsd.lv/ports.html |
systems is maintained at <http://mdocml.bsd.lv/ports.html>. |
|
|
If mandoc is installed, you can check the version by typing: mandoc -V |
If mandoc is installed, you can check the version by running "mandoc -V". |
The version contained in this distribution tarball is listed near |
You can find the version contained in this distribution tarball |
the beginning of the file "Makefile". Regarding how packages and |
by running "./configure". |
ports are maintained for your operating system, please consult your |
|
operating system documentation. |
|
|
|
|
Regarding how packages and ports are maintained for your operating |
|
system, please consult your operating system documentation. |
To install mandoc manually, the following steps are needed: |
To install mandoc manually, the following steps are needed: |
|
|
1. Decide whether you want to build just the basic tools mandoc(1), |
1. If you want to build the CGI program, man.cgi(8), too, run the |
preconv(1) and demandoc(1) or whether you also want to build the |
command "echo BUILD_CGI=1 > configure.local". Then run "cp |
database tools apropos(1) and makewhatis(8). For the latter, a |
cgi.h.examples cgi.h" and edit cgi.h as desired. |
working installation of SQLite is required, see: http://sqlite.org/ |
|
|
2. Run "./configure". |
|
This script attempts autoconfiguration of mandoc for your system. |
|
Read both its standard output and the file "Makefile.local" it |
|
generates. If anything looks wrong or different from what you |
|
wish, read the file "configure.local.example", create and edit |
|
a file "configure.local", and re-run "./configure" until the |
|
result seems right to you. |
|
|
|
3. Run "make". |
|
Any POSIX-compatible make, in particular both BSD make and GNU make, |
|
should work. If the build fails, look at "configure.local.example" |
|
and go back to step 2. |
|
|
|
4. Run "make -n install" and check whether everything will be |
|
installed to the intended places. Otherwise, put some *DIR or *NM* |
|
variables into "configure.local" and go back to step 2. |
|
|
|
5. Run "sudo make install". If you intend to build a binary |
|
package using some kind of fake root mechanism, you may need a |
|
command like "make DESTDIR=... install". Read the *-install targets |
|
in the "Makefile" to understand how DESTDIR is used. |
|
|
|
6. To set up a man.cgi(8) server, read its manual page. |
|
|
|
7. To use mandoc(1) as your man(1) formatter, read the "Deployment" |
|
sections below. |
|
|
|
|
|
Understanding mandoc dependencies |
|
--------------------------------- |
|
The mandoc(1) and demandoc(1) utilities have no external dependencies. |
|
However, makewhatis(8), apropos(1), and man(1) depend on the following |
|
software: |
|
|
|
1. The SQLite database system, see <http://sqlite.org/>. |
The recommended version of SQLite is 3.8.4.3 or newer. The mandoc |
The recommended version of SQLite is 3.8.4.3 or newer. The mandoc |
toolset is known to work with version 3.7.5 or newer. Versions |
toolset is known to work with version 3.7.5 or newer. Versions |
older than 3.8.3 may not achieve full performance due to the |
older than 3.8.3 may not achieve full performance due to the |
missing SQLITE_DETERMINISTIC optimization flag. Versions older |
missing SQLITE_DETERMINISTIC optimization flag. Versions older |
than 3.8.0 may not show full error information if opening a database |
than 3.8.0 may not show full error information if opening a database |
fails due to the missing sqlite3_errstr() API. Both are very minor |
fails due to the missing sqlite3_errstr() API. Both are very minor |
problems, apropos(1) is fully usable with SQLite 3.7.5. |
problems, apropos(1) is fully usable with SQLite 3.7.5. Versions |
The database tools also require Marc Espie's ohash(3) library; |
older than 3.7.5 may or may not work, they have not been tested. |
if your system does not have it, the bundled compatibility version |
|
will be used, so you probably need not worry about it. |
|
|
|
2. If you choose to build the database tools, too, decide whether |
2. The fts(3) directory traversion functions. |
you also want to build the CGI program, man.cgi(8). |
If your system does not have them, the bundled compatibility version |
|
will be used, so you need not worry in that case. But be careful: the |
|
glibc version of fts(3) is known to be broken on 32bit platforms, |
|
see <https://sourceware.org/bugzilla/show_bug.cgi?id=15838>. |
|
If you run into that problem, set "HAVE_FTS=0" in configure.local. |
|
|
3. Read the beginning of the file "Makefile" from "USER SETTINGS" |
3. Marc Espie's ohash(3) library. |
to "END OF USER SETTINGS" and edit it as required. In particular, |
If your system does not have it, the bundled compatibility version |
disable "BUILD_TARGETS += db-build" if you do not want database |
will be used, so you probably need not worry about it. |
support or enable "BUILD_TARGETS += cgi-build" if you do want |
|
the CGI program. |
|
|
|
4. Run the command "make". No separate "./configure" or "make |
|
depend" steps are needed. The former is run automatically by "make". |
|
The latter is a maintainer target. If you merely want to build the |
|
released version as opposed to doing active development, there is |
|
no need to regenerate the dependency specifications. Any |
|
POSIX-compatible make, in particular both BSD make and GNU make, |
|
is supposed to work. |
|
|
|
5. Run the command "make -n install" and check whether everything |
Checking autoconfiguration quality |
will be installed to the intended places. Otherwise, edit the *DIR |
---------------------------------- |
variables in the Makefile until it is. |
|
|
|
6. Run "sudo make install". Instead, if you intend to build a binary |
|
package using some kind of fake root mechanism, you may need a |
|
command like "make DESTDIR=... install". Read the *-install targets |
|
in the "Makefile" to understand how DESTDIR is used. |
|
|
|
|
|
If you want to check whether automatic configuration works well |
If you want to check whether automatic configuration works well |
on your platform, consider the following: |
on your platform, consider the following: |
|
|
Line 94 please report whatever is missing on your platform. |
|
Line 131 please report whatever is missing on your platform. |
|
The following steps can be used to manually check the automatic |
The following steps can be used to manually check the automatic |
configuration on your platform: |
configuration on your platform: |
|
|
1. Run "make clean". |
1. Run "make distclean". |
|
|
2. Run "make config.h" |
2. Run "./configure" |
|
|
3. Read the file "config.log". It shows the compiler commands used |
3. Read the file "config.log". It shows the compiler commands used |
to test the libraries installed on your system and the standard |
to test the libraries installed on your system and the standard |
Line 104 output and standard error output these commands produc |
|
Line 141 output and standard error output these commands produc |
|
for unexpected failures. Those are most likely to happen if headers |
for unexpected failures. Those are most likely to happen if headers |
or libraries are installed in unusual places or interfaces defined |
or libraries are installed in unusual places or interfaces defined |
in unusual headers. You can also look at the file "config.h" and |
in unusual headers. You can also look at the file "config.h" and |
check that no expected "#define HAVE_*" lines are missing. The |
check that no "#define HAVE_*" differ from your expectations. |
list of tests run can be found in the file "configure". |
|
|
|
|
|
In case you have questions or want to provide feedback, look at: |
Deployment using the integrated man(1) viewer |
http://mdocml.bsd.lv/contact.html |
--------------------------------------------- |
|
This mode of deployment requires database support. In case of |
|
doubt, look at the section "user settings related to database |
|
support" in the file configure.local.example. |
|
|
Consider subscribing to the discuss@ mailing list mentioned on that |
Deployment requires the following steps: |
page. If you intend to help with the development of mandoc, consider |
|
subscribing to the tech@ mailing list, too. |
|
|
|
Enjoy using the mandoc toolset! |
1. Build and install mandoc as described above in steps 2 to 5 |
Ingo Schwarze, Karlsruhe, August 2014 |
below "Installation". |
|
|
|
2. If your system uses manpath(1), make sure it is configured |
|
correctly, in particular, it returns all directory trees where |
|
manual pages are installed. If your system uses man.conf(5), make |
|
sure it contains a "_whatdb" line for each directory tree, and the |
|
order of these lines meets your wishes. |
|
|
|
3. Run the command "sudo makewhatis" to build mandoc.db(5) databases |
|
in all the directory trees configured in step 2. |
|
|
|
At this point, your new man(1), apropos(1), and whatis(1) should work. |
|
Otherwise, please look at <http://mdocml.bsd.lv/contact.html>, both |
|
for help and to have these instructions improved. |
|
|
|
Whenever installing new manual pages, re-run makewhatis(8) to update |
|
the databases, or man(1) will not find the new pages. |
|
|
|
|
|
Deployment using your system's native man(1) viewer |
|
--------------------------------------------------- |
|
This mode of deployment does not require database support, |
|
so it works even if you don't have SQLite3. |
|
|
|
Usually, you can have your default installation and mandoc(1) work right |
|
alongside each other by using user-specific versions of the files |
|
mentioned below. |
|
|
|
0. Back up each file you want to change! |
|
|
|
1. First see whether your system has "/etc/man.conf" or "/etc/manpath.conf" |
|
(if it has neither, but man(1) is functional, then let us know) or, |
|
if running as your own user, a per-user override file. In either |
|
case, find where man(1) is executing nroff(1) or groff(1) to format |
|
manuals. Replace these calls with mandoc(1). |
|
|
|
2. Then make sure that man(1) isn't running preprocessors, so you may |
|
need to replace tbl(1), eqn(1), and similar references with cat(1). |
|
Some man(1) implementations, like that on Mac OSX, let you run "man -d" |
|
to see how the formatter is invoked. Use this to test your changes. On |
|
Mac OS X, for instance, man(1) will prepend all files with ".ll" and |
|
".nr" to set the terminal size, so you need to pass "tail -n+2 | |
|
mandoc(1)" to disregard them. |
|
|
|
3. Finally, make sure that mandoc(1) is actually being invoked instead |
|
of cached pages being pulled up. You can usually do this by commenting |
|
out NOCACHE or similar. |
|
|
|
|
|
mandoc(1) still has a long way to go in understanding non-trivial |
|
low-level roff(7) markup embedded in some man(7) pages. On the BSD |
|
systems using mandoc(1), third-party software is generally vetted |
|
on whether it may be formatted with mandoc(1). If not, groff(1) |
|
is pulled in as a dependency and used to install a pre-formatted |
|
"catpage" instead of directly as manual page source. |
|
|
|
For more background on switching operating systems to use mandoc(1) |
|
instead of groff(1) to format manuals, see the two BSDCan presentations |
|
by Ingo Schwarze: |
|
<http://www.openbsd.org/papers/bsdcan11-mandoc-openbsd.html> |
|
<http://www.openbsd.org/papers/bsdcan14-mandoc.pdf> |