Re: organizing deep source trees with child packages

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Greg Moncreaff wrote on comp.lang.ada:
> 100's of files?  unless it was auto generated from a domain model,
> how can you possibly keep it organized as to what depends on what,
> what is separable, reusable; what deals with one interface/component/
> peer vs another,
> etc

Remember that Ada was designed for large-scale software engineering
and therefore provides tools to:

- encode dependencies, this is what "with" clauses are for.

- minimize dependencies by means of information hiding.  Private child
packages are your friends.  You normally design large modules as
hierarchies of packages; the top-level package provides the public
interface for the module and the private children provide the
implementation.

- keep track of dependencies: this is what gnatmake is for.

- build and maintain cross-references: that's (also) what the .ali
files produced by the compiler are for, and gnatfind is your friend.

Directories are *not* a solution for these problems.  They do not
represent dependencies or hide any information from the compiler.
They do not help navigate the sources; specialized tools like
gnatfind, GPS or Emacs ada-mode do a better job with or without
directories, and general tools like grep work better without
directories.

The one situation where I find directories useful is when I want to
build some of my sources as a shared library.  In this case I place
these sources into a separate directory, build them separately, and
then install the shared library along with sources, .ali files and a
project file in a read-only directory where the rest of the software
looks for them.  This only works well if the shared library is mature
and stable (i.e. does not change very often anymore).

BTW, I too work on large-scale software (over 2 million lines of
sources) where directories normally contain hundreds of source files.

--
Ludovic Brenta.