mandoc — Programs using libmandoc

Programs using libmandoc

Development of libmandoc(3) is a tightly integrated part of the development of the mandoc program. Development proceeds with flexibility in mind: when the needs of the mandoc program change, the API and ABI of libmandoc(3) will change accordingly with no notice whatsoever. Typically, incompatible changes of the library interface happen more often than mandoc releases. This development strategy is valuable because even though the mandoc program has been very stable software for about a decade now, a lot of active development is still going on both with respect to functionality and with respect to improvements of the internal code structure. Such development should not be impeded by compatibility requirements, nor should the code get encumbered with compatibility glue.

Of course, interface changes are inconvenient for third-party programs using the libmandoc(3) interface. For that reason, using that interface is not particularly recommended. If possible for the intended purpose, it is preferable and certainly much more robust to fork and execute a mandoc(1) child process.

The number of external projects using the unstable libmandoc(3) interface anyway is very small, and all are actively maintained such that they can adapt to new mandoc releases. If you use the libmandoc(3) interface in a program not listed here, please contact the mandoc authors to get listed. The purpose isn't that any stability promises would be made, but that we can keep track of what's out there and also to better evaluate the demand for API stability if that would ever be considered later, when mandoc internals have become more stable.

NetBSD: the apropos(1) program in the base system: This toolkit includes the makemandb(8) and whatis(1) utilities.
source code — build system linking against libmandoc.a, which is the recommended approach.
Fedora: the rpminspect(1) program: source code — build system linking against libmandoc.a — automatic builds