From: crispen@efftoo.boeing.com (crispen)
Newsgroups: comp.lang.ada
Subject: Re: Ada source module configuration
Date: 25 Aug 92 16:17:07 GMT
Distribution: world
Organization: The Internet

eachus@mitre-bedford.arpa  (Robert I. Eachus) shows an excellent
method for organizing Ada libraries.

Let me fill in a few elementary details.

First of all, on Sun you probably have Verdix Ada which allows you to
build multiple Ada libraries which you can then link together using an
"a.path" directive.  You are not bound to an enormous flat library
structure, which is good news.  I recommend that you have a library
in each subdirectory that has Ada code.  Note: the above is not an
endorsement of Verdix, but is a very strong personal endorsement of
the multiple local library feature for Ada compilers.

Secondly, you can have nested directories on a Sun so you can build
a directory tree that matches some aspects of your software tree.
Again this is good news.

Let me suggest that you have a hierarchy like the following:


                            /home/all_programs
                                  |
              ---------------------------------------------
              |            |              |               |
            types       common       this_program    that_program
                                          |
                          -------------------------------------
                          |       |       |         |         |
                        types  common  segment1  segment2  segment3
                                          |
                          ------------------------------
                          |       |       |            |
                        types  common  subsystem1  subsystem2


Note that the tree structure above doesn't account for product versions.
That issue is best left to you and your software clergyman ;-)

Notice that there is (potentially) a directory called "types" and
another directory called "common" at every level of the tree.  The
former contains types packages and the latter contains executable code.

Now we're ready to apply The Rule:  any compilation unit may go as
far up in the directory tree as it likes to find a package to WITH,
but it may only go down one directory after climbing up.  For example,
/home/all_programs/this_program/segment1/types may be WITHed by anything
in or below subsystem1 or subsystem2, but it may NOT be WITHed by
anything in segment2 or segment3.

There's probably a clearer way to express The Rule, but that gives
you an idea for what would be stored in the "common" and "types"
directories.  For example, subsystem1/types would contain type
declarations that would only be used in subsystem1; segment2/common
would contain code that is executed by several of the subsystems in
segment2.

Robert suggests that you have a librarian.  I second that.  From time
to time have him/her check the Makefiles at each level and make sure
that The Rule is being followed.  It's reasonable for useful types
and algorithms to migrate higher and higher in the tree.

If you do this, I believe you have absolutely isolated the
effects of change.  You know that any change in segment1/types
absolutely will not affect anything under segment2 or segment3.

Of course, if you have all your types packages in /home/program/types
then you're hosed.  And if you're using a flat pure-OOD style where
everybody can call everybody else, you might be hosed, too.  This
directory structure is really only good if you've got some kind of
hierarchical partitioning of your system.

BTW, I had been using shell scripts called INSTALL_ME or COMPILE_ME
and lately I've changed over to vanilla Unix Makefiles.  I don't bother
with make dependencies or fancy business (I'm not that good at makefiles
yet)  I just have a few make verbs like "install", "compile",
"cleanlib" and some things that do some SCCS tricks.

Hope this helps.  As always I speak only for me.

Bob Crispen
crispen@foxy.boeing.com
Newsgroups: comp.lang.ada