home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 2 / Apprentice-Release2.iso / Source Code / C / Libraries / stdwin / Conf / README < prev    next >
Encoding:
Text File  |  1990-08-08  |  5.1 KB  |  110 lines  |  [TEXT/????]
  1. Conf subdirectory
  2. -----------------
  3.  
  4. This directory contains tools (scrips) and data (Makefile fragments)
  5. used to build various ports of stdwin and applications that use it on
  6. various UNIX-based platforms.
  7.  
  8. An explanation of some of the terms used may be in order:
  9.  
  10. A "port" of stdwin consists of code that implements the portable stdwin
  11. interface on top of a particular lower-level interface, e.g., there is a
  12. port for X11, called "x11", and a port for ASCII terminals using the
  13. termcap library, called "alfa"; there are also ports to the Macintosh
  14. and the Atari ST, etc.  Ports can share code; in particular, some
  15. library packages built on top of stdwin (like "textedit") are used with
  16. all ports, and some low-level routines (like "strdup") are used by all
  17. ports.  Ports are structured as libraries that must be linked with
  18. applications.
  19.  
  20. A "platform" is a combination of operating system and machine
  21. architecture on which you might want to use stdwin.  The x11 and alfa
  22. ports work on many platforms, and most of those platforms support both
  23. ports.  The current set-up identifies platforms with architectures;
  24. while several operating systems are used on multiple architectures
  25. (e.g., SunOS on sun3 and sun4 architectures), few architectures offer a
  26. choice of operating system.  (If this simplification becomes a real
  27. problem, we'll simply change the maning of architecture identifiers into
  28. platform identifiers, so we might have platforms "ultvax" and "bsdvax"
  29. for a VAX under Ultrix and a VAX under BSD, respectively.)
  30.  
  31. A "component" is either a port library, a package library, or an
  32. application program.  Components are the smallest units that have
  33. Makefiles.  There is one set of sources for a particular component, used
  34. on all platforms.  Package and application components are also used with
  35. different ports, again using the same set of sources.
  36.  
  37. Objects live in a different part of the stdwin tree than sources.  This
  38. subtree is rooted at the Build subdirectory of the tree.  We certainly
  39. need a subtree per port, since two or more ports can co-exist on most
  40. platforms; but we also need a subtree per platform, since, through the
  41. wonders of NFS, a single file system containing the stdwin tree may be
  42. mounted on totally different systems.  Hence, the Build subtree has two
  43. levels of subdirectories before we are getting to business, one per
  44. architecture (really per platform), one per port.  The scripts have a
  45. few provisions to create build trees in nonstandard places if you need
  46. more freedom.
  47.  
  48. The subtree structure under Build is as follows:
  49.  
  50. Build/<arch>/            subtree for a particular architecture
  51.                 or platform (<arch> can be sun3, sun4,
  52.                 vax etc.)
  53.  
  54. Build/<arch>/<port>/        subtree for a particular port
  55.                 (<port> can be alfa or x11)
  56.  
  57. Build/<arch>/<port>/lib/    the main library component for the port
  58.                 is built here
  59.  
  60. Build/<arch>/<port>/lib/lib.a    library file to link with applications
  61.  
  62. Build/<arch>/<port>/<pack>/
  63. Build/<arch>/<port>/<appl>/    each application or package library
  64.                 component is built in its own
  65.                 subdirectory
  66.  
  67. The Makefiles are all generated automatically by scripts that live in
  68. the Conf subdirectory.  They are created from four sources:
  69.  
  70. a)    The concatenation of Makefile fragments that contain definitions
  71.     specific to:
  72.         - the port
  73.         - the architecture (or platform)
  74.         - the operating system
  75.     These fragments live in the Conf subdirectory.  Fragments for
  76.     all supported ports, and platforms are provided, as well as
  77.     templates that can be used to create new fragments.  These serve
  78.     as documentation for the fragments as well.
  79.  
  80. b)    A Makefile fragment specific to the component being built.
  81.     It defines which sources are needed and how they must be
  82.     combined.  The sources can come form any number of directories
  83.     besides the component's main source directory.  The object names
  84.     are derived from the source names.  There are two methods of
  85.     combining objects right now: libraries are created with "ar"
  86.     (and optionally "ranlib"), applications are created by linking
  87.     all objects together.  These Makefile fragments live in the main
  88.     source directory of the component (library or application) being
  89.     built.  The actual rules for building and creating the objects
  90.     are not contained in the fragments; rather, a bit of "bootstrap
  91.     magic" is used.
  92.  
  93. c)    The bootstrap magic consists of a Make rule in the
  94.     component-specific fragment.  This rule calls a program
  95.     "putprogmf" or "putlibmf" (depending on the component type) with
  96.     the list of source files used; the output is concatenated with
  97.     the Makefile fragments listed previously to produce a Makefile
  98.     that can build the component on the given platform using the
  99.     given port library (in case of an application).
  100.  
  101. d)    Full dependencies are added to the Makefile later.  Each
  102.     Makefile contains a rule "depend" which updates the Makefile
  103.     (in place!) with the current dependencies.  This should be run
  104.     once after the Makefile is built, and later when the dependency
  105.     structure of the sources is changed.  The dependencies are not
  106.     added when the Makefile is created initially, since the script
  107.     that computes dependencies *must* run on the platform where the
  108.     component is actually being built, while the Makefile can be
  109.     created (through NFS) from another platform.
  110.