home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2442 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  4.1 KB
  1. Path: sparky!uunet!sun-barr!ames!pacbell.com!att!ucbvax!efftoo.boeing.com!crispen
  2. From: crispen@efftoo.boeing.com (crispen)
  3. Newsgroups: comp.lang.ada
  4. Subject: Re: Ada source module configuration
  5. Message-ID: <9208251617.AA19346@efftoo.boeing.com>
  6. Date: 25 Aug 92 16:17:07 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 81
  11.  
  12. eachus@mitre-bedford.arpa  (Robert I. Eachus) shows an excellent
  13. method for organizing Ada libraries.
  14.  
  15. Let me fill in a few elementary details.
  16.  
  17. First of all, on Sun you probably have Verdix Ada which allows you to
  18. build multiple Ada libraries which you can then link together using an
  19. "a.path" directive.  You are not bound to an enormous flat library
  20. structure, which is good news.  I recommend that you have a library
  21. in each subdirectory that has Ada code.  Note: the above is not an
  22. endorsement of Verdix, but is a very strong personal endorsement of
  23. the multiple local library feature for Ada compilers.
  24.  
  25. Secondly, you can have nested directories on a Sun so you can build
  26. a directory tree that matches some aspects of your software tree.
  27. Again this is good news.
  28.  
  29. Let me suggest that you have a hierarchy like the following:
  30.  
  31.  
  32.                             /home/all_programs
  33.                                   |
  34.               ---------------------------------------------
  35.               |            |              |               |
  36.             types       common       this_program    that_program
  37.                                           |
  38.                           -------------------------------------
  39.                           |       |       |         |         |
  40.                         types  common  segment1  segment2  segment3
  41.                                           |
  42.                           ------------------------------
  43.                           |       |       |            |
  44.                         types  common  subsystem1  subsystem2
  45.  
  46.  
  47. Note that the tree structure above doesn't account for product versions.
  48. That issue is best left to you and your software clergyman ;-)
  49.  
  50. Notice that there is (potentially) a directory called "types" and
  51. another directory called "common" at every level of the tree.  The
  52. former contains types packages and the latter contains executable code.
  53.  
  54. Now we're ready to apply The Rule:  any compilation unit may go as
  55. far up in the directory tree as it likes to find a package to WITH,
  56. but it may only go down one directory after climbing up.  For example,
  57. /home/all_programs/this_program/segment1/types may be WITHed by anything
  58. in or below subsystem1 or subsystem2, but it may NOT be WITHed by
  59. anything in segment2 or segment3.
  60.  
  61. There's probably a clearer way to express The Rule, but that gives
  62. you an idea for what would be stored in the "common" and "types"
  63. directories.  For example, subsystem1/types would contain type
  64. declarations that would only be used in subsystem1; segment2/common
  65. would contain code that is executed by several of the subsystems in
  66. segment2.
  67.  
  68. Robert suggests that you have a librarian.  I second that.  From time
  69. to time have him/her check the Makefiles at each level and make sure
  70. that The Rule is being followed.  It's reasonable for useful types
  71. and algorithms to migrate higher and higher in the tree.
  72.  
  73. If you do this, I believe you have absolutely isolated the
  74. effects of change.  You know that any change in segment1/types
  75. absolutely will not affect anything under segment2 or segment3.
  76.  
  77. Of course, if you have all your types packages in /home/program/types
  78. then you're hosed.  And if you're using a flat pure-OOD style where
  79. everybody can call everybody else, you might be hosed, too.  This
  80. directory structure is really only good if you've got some kind of
  81. hierarchical partitioning of your system.
  82.  
  83. BTW, I had been using shell scripts called INSTALL_ME or COMPILE_ME
  84. and lately I've changed over to vanilla Unix Makefiles.  I don't bother
  85. with make dependencies or fancy business (I'm not that good at makefiles
  86. yet)  I just have a few make verbs like "install", "compile",
  87. "cleanlib" and some things that do some SCCS tricks.
  88.  
  89. Hope this helps.  As always I speak only for me.
  90.  
  91. Bob Crispen
  92. crispen@foxy.boeing.com
  93.