Re: The Dreaded "Missing Subunits"

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Emmanuel Briot <briot@act-europe.fr> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > >...Have a look in the documentation at pragma
> > > Source_File_Name, which provides handling for any possible naming scheme you
> > > can conceive.
> > 
> > This is also of course wrong.  The patterns supported by the pragma are
> > fairly limited, but I can "conceive" of many things.  For example, if
> > you want to put all main procedures in files with a certain pattern, it
> > doesn't really work.
> 
> Have a look at the more recent versions of GNAT (I don't know if the full
> support was already in 3.14p or was added later, although I think it was
> already there in 3.14p) for the project files.

I don't know.  Project files are in 3.14p, but I don't know about "full
support".  Please tell us what project files can do.

> Also have a look at pragma Source_File_Name, where you associate a unit name
> with *any* file name you want. There is no notion of naming scheme, since you
> can use a different one for each unit and even for specs and bodies for a given
> unit.

The form of pragma Source_File_Name that lists all the compilation units
and their file names is useless, in my opinion, unless there's an
automatic way to generate them (as you say below).

There is also a form of pragma Source_File_Name that takes a *pattern*,
which is sufficient to make GNAT understand, for example, the Rational
file-naming convention.  That's useful, but as I said, it's not very
general.

For example, I don't think GNAT will allow multiple compilation units in
one file.  That's rarely a good idea, but sometimes useful.  For
example, I would like to put package Ada.Text_IO and the renaming as
Text_IO in the same file.  For another example, small test programs
should usually go all in one file, even when they contain several
compilation units.

> Of course, it used to be a pain to generate these pragma Source_File_Name by
> hand. There is now a tool called gnatname that will scan your source
> directories to generate the pragmas directly.

The gnatname command does not exist in 3.14p.  I would consider this a
good solution only if it's fast enough to run it automatically *every*
time I do a build (e.g. the Makefile would do "gnatname" followed by
"gnatmake").  Is gnatname smart enough to re-scan only those files that
have changed (or have newly been created) since the last time I ran
gnatname?  And to delete whatever information is associated with files I
have deleted (or renamed) since the last time I ran gnatname?  If not,
I suspect it's too slow for large bodies of code.

Anyway, this all seems rather convoluted.  Why can't the
compiler/builder automatically determine which compilation units are in
which files?  Why is a separate tool needed?  And a separate file of
pragmas Source_File_Name to maintain?

Furthermore, none of this mumbo-jumbo would be necessary at all,
if only all Ada compilers agreed on the file naming convention.
(I must admit, that wasn't easy in the days when operating systems
had unreasonable limits on file names (like only one dot, or only 8
characters).  Are those bad-old-days over?)

I also admit that C has it easy in this regard, since it has no proper
notion of "module" separate from source file.

> So any naming scheme is supported, and yes, this is a challenge :-)

- Bob