libk  Check-in [8618103a4e]

 8. **modularity.** libk is not part of the C specification and it isn't always going to be practical for developers to expect the entire library to be present on the end-user's computer. so libk is designed to be usable in many different ways -- as a traditional library, as a static library, in full form or with only components needed by the developer, to be distributed either on its own or as part of a binary.
 9. **compatibility.** code that links against libk should be able to compile and run on any operating system. in the ideal case (Linux or FreeBSD) it will be able to do so without touching any other system libraries; for less ideal environments like Windows, libk will when necessary abstract over system libraries or libc itself.
 10. **sane error-handling.** every time you type `errno` god murders a puppy.
 11. **ease of distribution.** libk should enable to user to create completely static binaries, free of any local dependency and trivial to distribute.

# dependencies

libk is designed to be as portable and depedency-free as possible. ideally, it will be possible to compile code against libk using nothing but libk itself.

compiling libk is also designed to be as easy as possible. it has only two external dependencies, the macro processor [m4], needed for compile-time header generation, and optionally the [commonmark] compiler `cmark`, which is only needed if you wish to typeset the documentation in manpage, html, or pdf format. this process also requires `groff`, but `groff` is a standard part of most UNIX systems.

 [m4]: http://www.gnu.org/software/m4
 [commonmark]: http://www.commonmark.org/

a different macro processor, gpp, was used in early versions of libk, however, it was so obscure and took so much overly fragile infrastructure to make it work that the cleaner syntax just wasn't worth it; i've since deleted the gpp infra and ported the macro files to m4.

 8. **modularity.** libk is not part of the C specification and it isn't always going to be practical for developers to expect the entire library to be present on the end-user's computer. so libk is designed to be usable in many different ways -- as a traditional library, as a static library, in full form or with only components needed by the developer, to be distributed either on its own or as part of a binary.
 9. **compatibility.** code that links against libk should be able to compile and run on any operating system. in the ideal case (Linux or FreeBSD) it will be able to do so without touching any other system libraries; for less ideal environments like Windows, libk will when necessary abstract over system libraries or libc itself.
 10. **sane error-handling.** every time you type `errno` god murders a puppy.
 11. **ease of distribution.** libk should enable to user to create completely static binaries, free of any local dependency and trivial to distribute.

# dependencies

libk is designed to be as portable and dependency-free as possible. ideally, it will be possible to compile code against libk using nothing but libk itself.

compiling libk is also designed to be as easy as possible. it has only two external dependencies, the macro processor [m4], needed for compile-time header generation, and optionally the [commonmark] compiler `cmark`, which is only needed if you wish to typeset the documentation in manpage, html, or pdf format. this process also requires `groff`, but `groff` is a standard part of most UNIX systems.

 [m4]: http://www.gnu.org/software/m4
 [commonmark]: http://www.commonmark.org/

a different macro processor, gpp, was used in early versions of libk, however, it was so obscure and took so much overly fragile infrastructure to make it work that the cleaner syntax just wasn't worth it; i've since deleted the gpp infra and ported the macro files to m4.