home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 1 / 1342 / PORTING < prev   
Encoding:
Text File  |  1990-12-28  |  4.6 KB  |  119 lines
  1.  
  2. Porting KEF
  3. ===========
  4.  
  5. 1.)    Getting started
  6.  
  7.     Now that you have got KEF from somewhere you want to test and see
  8.     what it is for, what it is like and whether it is useful for you.
  9.  
  10.     First unpack the routines from whatever form you got them in in
  11.     an empty directory. Let's call this directory the "top level
  12.     directory".
  13.     There should be several directories with C source files in them.
  14.     See MANIFEST for a complete list of names.
  15.  
  16.     The sources will eventually produces several files:
  17.     - libkef.a : the KEF library
  18.     - libDkef.a : a library of routines to dump and test KEF structures; not
  19.         documented yet
  20.     - kef.h : a headerfile for inclusion in any programs that use KEF
  21.     - several man files for the parts of KEF in the subdirectories
  22.     - demo programs
  23.  
  24. 2.) Building KEF.
  25.  
  26.     If your system is a UNIX system or a UNIX-derived one, you will
  27.     probably have no problems.
  28.     
  29.     a) Run Configure as "sh Configure"
  30.  
  31.         "Configure" is a Bourne-shell script that finds out things about
  32.         the system it is running on, relevant to the software package for which
  33.         "Configure" was created. It either searches header files and
  34.         libraries or asks the user directly for information.
  35.         "Configure" should be called only from the top level directory of
  36.         the source tree for a software package.
  37.         "Configure" does the following:
  38.         - looks up each file listed in MANIFEST to see if the kit
  39.             is complete. You can skip this step by calling "Configure"
  40.             as "sh Configure -f"
  41.         - finds out about the system, both automatically and by asking
  42.             the user.
  43.         - generates a file "config.sh"
  44.         - offers to unpack, or "run", the files with suffix ".SH". You can
  45.             tell "Configure" that it should do so, but you can also do it
  46.             yourself.
  47.  
  48.         "config.sh" is a Bourne-shell script that assigns values to a lot
  49.         of shell variables.
  50.         In the package there are some files whose names have the suffix ".SH".
  51.         These files contain shell scripts that read "config.sh" and generate
  52.         files with the same name but ".SH" deleted.
  53.         Typically there is a file "config.h.SH" that generates "config.h", which
  54.         is used in the source files to get information about the system.
  55.  
  56.         If you make any errors in "Configure", either rerun "Configure"
  57.         or change the values in config.h or config.sh by hand.
  58.         Remember that any changes made to config.sh or config.h are lost
  59.         when you rerun Configure.
  60.  
  61.         You can skip this step. In directory "cfg" there are several files
  62.         for some systems on which I have built KEF previously (see below).
  63.         Copy such a file to "config.sh" to the top level directory.
  64.         You can now unpack the "*.SH" files by simply saying "sh file.SH"
  65.         to create "file".
  66.  
  67.     b)    Now you can type "make" in the top level directory.
  68.         "libkef.a" and "libDkef.a" and "config.h" will be created in the
  69.         top level directory.
  70.  
  71.     c)    In the directory "demos" there are some demo programs.
  72.         Run them to make sure, kef works as expected.
  73.     
  74.  
  75. 3.)    What if something does not work?
  76.  
  77.     If your system is not running UNIX or a UNIX-derived OS, you may
  78.     have problems.
  79.  
  80.     If you don't know how to switch your system's driver to hand characters
  81.     to a program as soon as they are typed and none of the UNIX-like
  82.     ways work, you might as well give up.
  83.  
  84.     Currently "kef" is known to work on
  85.  
  86.     - SIEMENS PC MX2; SINIX 2.1
  87.     - SUN 3/260; SUN OS 3.5
  88.     - VAX 11/780; UNIX 4.3 BSD
  89.     - VAX 8700; ULTRIX 2.0
  90.  
  91.     (Not much, eh? Well I am counting on people on USENET to supply many more.)
  92.  
  93.     If you have such a system and still it does not work, check the
  94.     defines in config.h.
  95.  
  96.     In directory "cfg" there are some prototypical "config.sh" files for
  97.     some systems. These files are named after the system they were built on
  98.     and reflect the decisions and results of installing KEF on a specific
  99.     system. You may want to change some things, like file names, or you may
  100.     wish to substitute "gcc" for the standard compiler. KEF compiles with
  101.     gcc v 1.37.1.
  102.  
  103.     If you are porting to a different system, where even some of the
  104.     UNIX system calls are not available, like VMS or MS-DOS, you can
  105.     check the following:
  106.     - there is one call to "read" in kef/fill.c. Check the semantics
  107.         of your systems basic read-function.
  108.     - the routines to wait for characters to become available are
  109.         in kef/look_wait.c. Roll your own.
  110.     - in demos/set_io.c there are routines to put the terminal
  111.         driver in a mode where it passes any characters typed directly
  112.         to the program. Write the routines necessary for your OS.
  113.         (I have routines for VMS, but they are not working to my
  114.         satisfaction yet : ^Y does not work anymore. I don't have the
  115.         time to read the manuals and I lack the experience with VMS IO
  116.         to foresee any problems. So it's up to you.)
  117.  
  118.     If you have questions, drop me a note.
  119.