111 lines
		
	
	
		
			5.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			111 lines
		
	
	
		
			5.5 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 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 and SEEALSO 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.  add file to something.tex;
 | |
| 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.
 |