This HOWTO file contains notes for maintainers and contributors to Newlib. For information on using Newlib (building, installing), see README. (In particular, the "Regenerating Configuration Files" section in README is of interest to both users and contributors.) (This file could probably use some other "sections" in addition to the initially-provided sections. Please help by adding as appropriate.) DOCUMENTATION ============= All the documentation for Newlib comes as part of the machine-readable distribution. Functions are documented in the source files, although not every file contains documentation, as many functions share manual page information. For example, lround(), lroundf(), llround(), and llroundf() share a single man page, which is in the source for lround(). The documentation is written partially in a custom format and partially in Texinfo format. The custom part comprises makedoc.c and doc.str, both of which are in the doc directory. doc.str is a macro file that can be used to define things to be done by makedoc, using building blocks that are built into makedoc.c. The basic function of makedoc is two-fold. First, it recognizes comments in the proper format to pull out of source files. Second, it adds some Texinfo commands as well as translating certain sequences into the appropriate Texinfo commands. Refer to makedoc.c and doc.str for what these are. (makedoc.c is not particularly-well commented.) Another way to see how they work is to simply examine the source files with documentation comments. (A couple of examples that use some of the fancier options: libm/common/s_isnan.c ("o+" variable-"bullet" list), libc/stdio/sprintf.c ("O+" bullet list; "." for example code).) In addition to the makedoc.c stuff, Texinfo commands can be directly used. Texinfo is a documentation system that uses a single source file to produce both on-line information and a printed manual. You can use one of the Info formatting commands to create the on-line version of the documentation and TeX (or `texi2roff') to typeset the printed version. While Newlib contains a copy of the texinfo package (texinfo.tex), the manual for it is not included. The latest one may be found at http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html (which could be for a newer version of texinfo.tex than is included in Newlib). In addition to Texinfo commands, straight TeX commands can also be used, but these, however, should be carefully limited and be given alternates for when a non-printed manual is produced--such as when info pages are produced. For an example of this kind of usage, see libm/common/s_logb.c. If writing a new function that requires documentation, the required sections are FUNCTION, INDEX, SYNOPSIS, DESCRIPTION, RETURNS, and PORTABILITY. BUGS, NOTES, SEEALSO and WARNINGS should be added as appropriate. Source files which contain documentation are processed into ".def" files with the extracted information. These .def files are noted in the makefiles as CHEWOUT_FILES. These .def files need to be included into an appropriate .tex file for inclusion in the manuals (one each for libc and libm). Pay special attention under libc, as the manual is arranged by header file name, but not all header files are represented by directories (e.g. wcsftime.c is found under libc/time, but goes under wchar.h in the manual.) In summary, to add new documentation: 1. Add properly-formatted comments to source file (e.g. src.c); 2. add "chewout" file to CHEWOUT_FILES list in Makefile.am (e.g. src.def), re-generate Makefile.in; 3. @include that .def file in the appropriate .tex file, add texinfo menu entries that reference the @node(s) in that .def file; 4. make ChangeLog entry and generate patch. EL/IX (ELIX_LEVEL_n, ELIX_n_SOURCES) ==================================== Some of the Makefiles contain definitions of ELIX_LEVEL_1 ... ELIX_LEVEL_4, and corresponding definitions for ELIX_1_SOURCES ... ELIX_4_SOURCES. These are referring to the EL/IX standards created by Red Hat for the purpose of Linux-based open standards for embedded development. In brief, the intent is to define multiple levels for API functions that allows the user to size the library appropriately for their application--at least in terms of the predefined lists. For full details, refer to the EL/IX home page at http://sourceware.org/elix/. The likely best way to tell how to classify any new functions in terms of needing an ELIX level qualification is to ask Jeff Johnston. To see how it works and try classification on your own, refer to the API specification on the web site, http://sourceware.org/elix/api/current/api.pdf. (Unfortunately, it is not complete with respect to either the C99 or POSIX standards, so particular C and POSIX functions may or may not be found.) The following definitions of the levels are from the (draft) standard. Level 1 RTOS compatible layer. Functions available in both Linux and a typical deeply embedded operating system (eCos, RTEMS, VxWorks, pSOS, VRTX32, etc.). Some functions may have reduced or modified semantics. Level 2 Linux single process only. Includes level 1 plus any functions from Linux that are not easily implemented on an RTOS. Also full implementations of reduced functions in Level 1. Level 3 Linux multiprocess for embedded applications. This is basically POSIX.1 with some of the functions that are obviously not for embedded applications (such as job control) removed. Level 4 Full POSIX or Linux compliance. Essentially these are functions that are present in a standard Linux kernel but are irrelevant to an embedded system. These functions do not form part of the EL/IX API.