Re: The Dreaded "Missing Subunits"

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

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > 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?
> 
> In order for the compiler to determine which compilation units are in
> which files, it has to read all the files in the compilation
> environment, build the list of file -> unit name mappings, and then
> compile them. gnatname + gnatmake does this (caveat; I don't use
> gnatname). 

No, it does not have to do all that every time you rebuild.

I am writing a tool that analyzes Ada programs.  It's not a compiler,
but it has the same issues with respect to this discussion (how to find
package Mumble when somebody says "with Mumble;").  I didn't want to
build in the conventions of any particular Ada compiler.  The solution I
chose is that the user specifies a wildcard specification of which files
constitute the "universe" (or the "program library").  So you might say
"*.ada" or "*.ads and *.adb".  Or you might mention several directories.
You can tell the tool whatever conventions you use (presumably whatever
your Ada compiler wants you to use).  This is in some sort of config
file.

Every time you tell the tool to re-analyze the world, it has to do this:
(1) Expand the wildcard(s), to see if there are any new files or any
files have been deleted.  Then (2) check the timestamp on each source
file to see if it has been changed.  Then it has to re-parse all the
files that have changed, or are new (and it has to forget about
information related to deleted files).  This process is quite fast, even
for large programs.  It's essentially what 'make' does when you say
'make main_program', or what 'gnatmake' does when told to build a
program.

(Actually, it also has to notice when the config file itself is
changed.)

The point is: it doesn't have to reparse *all* the source code -- just
what has changed since last time, and it can detect those files quickly.
(Of course, the *first* time you run it, it has to parse *all* the
source code.)  An Ada compiler could do likewise, but none do.

> You said this would be "too slow"; which requirement do you really
> want? speed or naming convenience?

I want both.  ;-)

I outlined above how to achieve it.

> It's faster if you cache the results of the name scan; gnatname does
> this. But as you say, the make system has to be able to determine when
> to rerun gnatname, or do it incrementally.
> 
> One of the requirements of the GNAT design is the source-based
> "library"; there are no data structures required to run the compiler,
> other than the source files. Running gnatname automatically starts to
> violate this principle.

The tool I mentioned above is entirely source based.

> ObjectAda takes a different approach; you have to manually tell it
> what files are in the compilation environment (at least, last time I
> used it; one reason I gave it up :). No possibility to automatically
> rescan for new files.

I think ObjectAda allows you to use the "adareg" command to "register"
new Ada source files.  It's similar to the gnatname idea.

> > Furthermore, none of this mumbo-jumbo would be necessary at all, if
> > only all Ada compilers agreed on the file naming convention. 
> 
> Doesn't seem likely, especially now.

True.  I'm just griping -- not expecting any improvement.  ;-)

> > (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 hope they are over. But we are stuck with their legacy; all of the
> GNAT compiler source files are krunched to 8.3 names.

Yeah, I find that annoying.

> > I also admit that C has it easy in this regard, since it has no
> > proper notion of "module" separate from source file.
> 
> That is part of the problem.
> 
> -- 
> -- Stephe

- Bob