hackguide.doc

ncurses-5.4 需要的就来下把 一定会有用的哦

   scripts  actually  write  C  initializers  which  are  linked  to  the
   compiler. Furthermore, the hash table is generated in the same way, so
   it  doesn't  have  to  be  generated at compiler startup time (another
   benefit  of  this  organization  is  that  the  hash  table  can be in
   shareable text space).

   Thus, adding a new capability is usually pretty trivial, just a matter
   of  adding  one  line to the include/Caps file. We'll have more to say
   about this in the section on Source-Form Translation.

Use Capability Resolution

   The  background  problem  that  makes  tic tricky isn't the capability
   translation  itself,  it's  the  resolution of use capabilities. Older
   versions would not handle forward use references for this reason (that
   is, a using terminal always had to follow its use target in the source
   file).  By  doing  this,  they  got  away with a simple implementation
   tactic;  compile  everything  as  it  blows by, then resolve uses from
   compiled entries.

   This  won't  do  for  ncurses.  The  problem  is  that  that the whole
   compilation  process  has  to  be embeddable in the ncurses library so
   that it can be called by the startup code to translate termcap entries
   on  the  fly.  The  embedded  version  can't  go promiscuously writing
   everything  it  translates  out  to  disk  --  for  one thing, it will
   typically be running with non-root permissions.

   So  our  tic  is  designed  to  parse  an  entire terminfo file into a
   doubly-linked  circular  list of entry structures in-core, and then do
   use  resolution  in-memory  before writing everything out. This design
   has other advantages: it makes forward and back use-references equally
   easy  (so  we get the latter for free), and it makes checking for name
   collisions before they're written out easy to do.

   And   this  is  exactly  how  the  embedded  version  works.  But  the
   stand-alone  user-accessible  version  of  tic  partly  reverts to the
   historical strategy; it writes to disk (not keeping in core) any entry
   with no use references.

   This  is  strictly  a  core-economy  kluge,  implemented  because  the
   terminfo  master file is large enough that some core-poor systems swap
   like crazy when you compile it all in memory...there have been reports
   of  this process taking three hours, rather than the twenty seconds or
   less typical on the author's development box.

   So. The executable tic passes the entry-parser a hook that immediately
   writes  out  the  referenced  entry if it has no use capabilities. The
   compiler  main loop refrains from adding the entry to the in-core list
   when  this hook fires. If some other entry later needs to reference an
   entry  that  got  written  immediately, that's OK; the resolution code
   will fetch it off disk when it can't find it in core.

   Name  collisions  will  still  be  detected,  just not as cleanly. The
   write_entry()   code   complains  before  overwriting  an  entry  that
   postdates  the time of tic's first call to write_entry(), Thus it will
   complain  about overwriting entries newly made during the tic run, but
   not about overwriting ones that predate it.

Source-Form Translation

   Another use of tic is to do source translation between various termcap
   and terminfo formats. There are more variants out there than you might
   think; the ones we know about are described in the captoinfo(1) manual
   page.

   The  translation output code (dump_entry() in ncurses/dump_entry.c) is
   shared  with  the  infocmp(1)  utility.  It  takes  the  same internal
   representation  used  to  generate  the  binary  form  and dumps it to
   standard output in a specified format.

   The  include/Caps  file  has  a header comment describing ways you can
   specify  source  translations  for  nonstandard  capabilities  just by
   altering the master table. It's possible to set up capability aliasing
   or  tell  the  compiler  to  plain  ignore  a given capability without
   writing any C code at all.

   For  circumstances where you need to do algorithmic translation, there
   are  functions  in  parse_entry.c called after the parse of each entry
   that are specifically intended to encapsulate such translations. This,
   for  example,  is  where  the AIX box1 capability get translated to an
   acsc string.

                                Other Utilities

   The  infocmp  utility  is just a wrapper around the same entry-dumping
   code  used  by tic for source translation. Perhaps the one interesting
   aspect  of  the  code  is the use of a predicate function passed in to
   dump_entry()  to  control  which  capabilities  are  dumped.  This  is
   necessary in order to handle both the ordinary De-compilation case and
   entry difference reporting.

   The  tput  and  clear  utilities  just  do an entry load followed by a
   tputs() of a selected capability.

                           Style Tips for Developers

   See   the  TO-DO  file  in  the  top-level  directory  of  the  source
   distribution for additions that would be particularly useful.

   The  prefix  _nc_  should be used on library public functions that are
   not  part  of  the  curses  API  in  order to prevent pollution of the
   application  namespace.  If  you have to add to or modify the function
   prototypes  in curses.h.in, read ncurses/MKlib_gen.sh first so you can
   avoid  breaking XSI conformance. Please join the ncurses mailing list.
   See  the INSTALL file in the top level of the distribution for details
   on the list.

   Look  for  the  string  FIXME  in  source  files to tag minor bugs and
   potential problems that could use fixing.

   Don't  try  to auto-detect OS features in the main body of the C code.
   That's the job of the configuration system.

   To hold down complexity, do make your code data-driven. Especially, if
   you  can drive logic from a table filtered out of include/Caps, do it.
   If  you  find  you  need  to augment the data in that file in order to
   generate  the  proper table, that's still preferable to ad-hoc code --
   that's why the fifth field (flags) is there.

   Have fun!

                                 Porting Hints

   The  following  notes  are intended to be a first step towards DOS and
   Macintosh ports of the ncurses libraries.

   The  following library modules are `pure curses'; they operate only on
   the  curses  internal  structures,  do all output through other curses
   calls  (not  including  tputs()  and putp()) and do not call any other
   UNIX  routines  such  as  signal(2)  or  the stdio library. Thus, they
   should not need to be modified for single-terminal ports.

     lib_addch.c    lib_addstr.c    lib_bkgd.c   lib_box.c   lib_clear.c
     lib_clrbot.c   lib_clreol.c  lib_delch.c  lib_delwin.c  lib_erase.c
     lib_inchstr.c  lib_insch.c  lib_insdel.c lib_insstr.c lib_keyname.c
     lib_move.c   lib_mvwin.c   lib_newwin.c   lib_overlay.c   lib_pad.c
     lib_printw.c  lib_refresh.c  lib_scanw.c  lib_scroll.c lib_scrreg.c
     lib_set_term.c  lib_touch.c  lib_tparm.c  lib_tputs.c  lib_unctrl.c
     lib_window.c panel.c

   This module is pure curses, but calls outstr():

     lib_getstr.c

   These  modules  are  pure  curses,  except  that  they use tputs() and
   putp():

     lib_beep.c   lib_color.c   lib_endwin.c   lib_options.c   lib_slk.c
     lib_vidattr.c

   This modules assist in POSIX emulation on non-POSIX systems:

   sigaction.c
          signal calls

   The    following   source   files   will   not   be   needed   for   a
   single-terminal-type port.

     alloc_entry.c   captoinfo.c   clear.c   comp_captab.c  comp_error.c
     comp_hash.c   comp_main.c   comp_parse.c  comp_scan.c  dump_entry.c
     infocmp.c parse_entry.c read_entry.c tput.c write_entry.c

   The  following  modules will use open()/read()/write()/close()/lseek()
   on files, but no other OS calls.

   lib_screen.c
          used to read/write screen dumps

   lib_trace.c
          used to write trace data to the logfile

   Modules that would have to be modified for a port start here:

   The  following  modules  are  `pure  curses'  but  contain assumptions
   inappropriate for a memory-mapped port.

   lib_longname.c
          assumes there may be multiple terminals

   lib_acs.c
          assumes acs_map as a double indirection

   lib_mvcur.c
          assumes cursor moves have variable cost

   lib_termcap.c
          assumes there may be multiple terminals

   lib_ti.c
          assumes there may be multiple terminals

   The following modules use UNIX-specific calls:

   lib_doupdate.c
          input checking

   lib_getch.c
          read()

   lib_initscr.c
          getenv()

   lib_newterm.c
   lib_baudrate.c
   lib_kernel.c
          various tty-manipulation and system calls

   lib_raw.c
          various tty-manipulation calls

   lib_setup.c
          various tty-manipulation calls

   lib_restart.c
          various tty-manipulation calls

   lib_tstp.c
          signal-manipulation calls

   lib_twait.c
          gettimeofday(), select().
     _________________________________________________________________


    Eric S. Raymond <[e-mail]>

   (Note: This is not the bug address!)