Re: organizing deep source trees with child packages

[Stephen Leake <stephen_leake@stephe-leake.org>]

Greg Moncreaff <moncreg@gmail.com> writes:

> On Oct 13, 4:20 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>>
>> Drop the directory tree; use a flat directory with full file names:
>>
>>
>> In my view, directories are for very large groupings of files; I often
>> have hundreds of Ada files in one directory.
>>
>
> In this case the files have coherence at the leaf level (same
> functional group, standard)
> but the middle levels will change (new adds, old removes)
>
> 100's of files?  unless it was auto generated from a domain model,

No, all hand-written over several years.

> how can you possibly keep it organized as to what depends on what,

That's what "with" is for; the file names don't indicate that (and
therefore your directory names don't either).

> what is separable, 

I'm not clear what you mean my "separable". In one sense, every Ada file
is already "separate".

'with' indicates everything needed for successful compilation, and
therefore for successful operation.

> reusable;

There are some directories, just not nearly as many as you have. My GDS
project looks like this:

sal; reusable
    math and data structures

opentoken; reusable

common ; reusable
    base
        core infrastructure
    models
        standard modules
    hardware
        interfacing to real hardware (analog IO, digital IO)
    1553
        modules that send packets over 1553
    spacewire
        modules that send packets over spacewire

mission; mission specific combinations of sal, common
    
80% of the code is in sal, opentoken, common.

each directory has a 'test' subdirectory.

> what deals with one interface/component/ peer vs another,

The file names don't really do that; how do you tell that
gds-models-reaction_wheel-adcole needs to interface to
gds-hardware-analog_out, but gds-models-reaction_wheel-gsfc needs to
interface to gds-hardware-1553?

In GDS, that information is implicit in the types of the input/output
symbols declared by the modules (these are _not_ just Ada parameter
lists, but items in a runtime symbol table). It is also stated in the
GDS user guide.

Repeating the file name in the directory name doesn't add any
information. So how do you do this?

The high level directory grouping is useful. Although if I was starting
over, I'd move the 1553 and spacewire directories into the hardware
directory; there's really no need to keep them separate. They were
separate in the first place because I was not sure how complicated they
would be when first starting on them, and because the tests were
structured differently than the other hardware tests. But that
difference has become less over time, as I've refactored things.


Give me a specific example; when is repeating the file name in the
directory name useful? 

What operation is possible/much more efficient on a directory with only
a few files than on a directory with lots of files?

Searching is easier in a flat directory; to find all of the files that
mention "serial", I can just do 'grep' in the common/hardware directory.
With your convention, I'd have to do 'find | grep'. Not a huge deal,
but not necessary, either. Sometimes I have to do find | grep as well,
since I do have some directories.

Organizing the tests is simpler in flat directories; it's much easier to
tell that you've got all the tests listed in the test harness.

People can get used to anything; it's often hard to really analyze why
we like a particular system, beyond "that's what I'm used to".

-- 
-- Stephe