The Dreaded "Missing Subunits"

The Dreaded "Missing Subunits"

[Peter Richtmyer]

I love the Gnat compiler but...

   I dread this error message:

   "No code generated for file xxxx.2.ada (missing subunits)"

It means that I have a procedure or function declared "...is separate;"
in package xxxx, but there is no matching separate. A "legacy" package 
has a gazillion separates. They need changes, and the calling 
parameters get changed and don't match, or the routine name changes, 
or the separate filename isn't right, or whatever happens to get this 
message, and it is a real pain to figure out which "subunit" is missing.

Anybody have a solution? maybe a compile switch or ...?

thanks,
Peter
 
(I know he isn't reading this but, Robert, I did try to read the docs!)

Re: The Dreaded "Missing Subunits"

[Peter Amey]

Peter Richtmyer wrote:
> 
> I love the Gnat compiler but...
> 
>    I dread this error message:
> 
>    "No code generated for file xxxx.2.ada (missing subunits)"
> 
> It means that I have a procedure or function declared "...is separate;"
> in package xxxx, but there is no matching separate. A "legacy" package
> has a gazillion separates. They need changes, and the calling
> parameters get changed and don't match, or the routine name changes,
> or the separate filename isn't right, or whatever happens to get this
> message, and it is a real pain to figure out which "subunit" is missing.
> 
> Anybody have a solution? maybe a compile switch or ...?
> 

Are you really using the GNAT compiler with Rational naming
conventions?  I don't know if that is the cause of your problem but it
certainly won't help.  Rational (rather bizarrely in my view) use
xxx.1.ada for specs and xxx.2.ada for bodies.  The GNAT convention
(which automates builds) is to use:

unit_name.ads for specs, unit_name.adb for bodies and
grandparent-parent-unit_name.adb for subunits.

Hope this helps.

Peter

Ada2005 temp solo child (was: Re: The Dreaded "Missing Subunits"

[Peter Hermann]

Peter Amey <peter.amey@praxis-cs.co.uk> wrote:
> grandparent-parent-unit_name.adb for subunits.

In this context I have a question to language lawyers:
Since it may be practical to temporarily have package children
without having the corresponding parent, why should it be 
prohibited by the standard to allow this?
Likewise e.g. ada.text_io could turn to orphan
since package ada may easily be missing.

While developing an application, I have e.g. a parent.child
but not yet a parent package, which may or may come later.
Now my compiler forces me to have the parent.
I would prefer the ada standard would force the compiler
to allow parentless children.
Did I ignore some important aspect?

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada2005 temp solo child (was: Re: The Dreaded "Missing Subunits"

[Robert A Duff]

Peter Hermann <ica2ph@iris16.csv.ica.uni-stuttgart.de> writes:

> Peter Amey <peter.amey@praxis-cs.co.uk> wrote:
> > grandparent-parent-unit_name.adb for subunits.
> 
> In this context I have a question to language lawyers:
> Since it may be practical to temporarily have package children
> without having the corresponding parent, why should it be 
> prohibited by the standard to allow this?

When you say "package A.B is..." you are referring to package A.  The
name A has to refer to some package declaration.  Otherwise the whole
model of visibility in Ada doesn't work (names denote declarations,
sometimes implicit.)  You might also write "with A;" temporarily before
you have written package A.  So you could ask the same question there --
why does the compiler complain when I say "with A;" and A does not
exist.

Therefore, I think what you're really asking for is that if A does not
exist (in the compilation environment), then "package A.B is..." should
mean that an empty package A is implicitly declared.  That could work,
but I don't think it's a good idea:

You can easily write an empty package A if you like.  So why should the
compiler go to extra trouble to invent empty packages out of thin air?

If Robert Dewar were listening, he would no doubt point out that
readability is the key (not the minor pain of *writing* the empty
package).  He's right.  If empty packages were imagined by the compiler,
then when I see "package A.B is..." I have a problem.  Suppose I can't
find the source code for A.  Perhaps I was looking in the wrong
directory.  Or perhaps A is implicitly empty.  How do I (as the reader
of the code) know which it is?

Furthermore, if the compiler is supposed to imagine empty packages,
how empty should they be?  Should they contain "pragma Pure;" by
default?  Perhaps, but suppose I write "package A.B.C is..." and A
exists, but B does not.  A pragma Pure in B might be illegal (because
maybe A is not Pure).

> Likewise e.g. ada.text_io could turn to orphan
> since package ada may easily be missing.

I'm not sure what you mean by that.  Package Ada is predefined in the
RM, and provided by all implementations of Ada.  How could it by
"missing" unless you incorrectly installed your compiler?
Perhaps you mean, package Ada could be implicitly empty in the RM (but
then where does its pragma Pure come from?).  I see no advantage in that
kind of implicit declaration.  (Suppose you were reading the RM, and you
couldn't find the declaration of package Ada anywhere.  Wouldn't that be
confusing?)

> While developing an application, I have e.g. a parent.child
> but not yet a parent package, which may or may come later.
> Now my compiler forces me to have the parent.
> I would prefer the ada standard would force the compiler
> to allow parentless children.
> Did I ignore some important aspect?

The Ada package hierarchy is analogous to directory hierarchies.
It makes perfect sense to have a directory with no files in it,
except nested subdirectories.  But it makes no sense to have a
subdirectory of A when A does not exist.

Therefore, I think it is good that when you refer to A (via "with A;" or
"package A.B is...") the compiler will complain if A does not exist.
If you like, create an empty package A to make the compiler shut up.

- Bob

Re: The Dreaded "Missing Subunits"

[Emmanuel Briot]

Peter Amey <peter.amey@praxis-cs.co.uk> writes:

> Are you really using the GNAT compiler with Rational naming
> conventions?  I don't know if that is the cause of your problem but it
> certainly won't help.  Rational (rather bizarrely in my view) use
> xxx.1.ada for specs and xxx.2.ada for bodies.  The GNAT convention
> (which automates builds) is to use:
> 
> unit_name.ads for specs, unit_name.adb for bodies and
> grandparent-parent-unit_name.adb for subunits.


This is of course wrong. Have a look in the documentation at pragma
Source_File_Name, which provides handling for any possible naming scheme you
can conceive.

Emmanuel

Re: The Dreaded "Missing Subunits"

[Simon Wright]

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

> This is of course wrong. Have a look in the documentation at pragma
> Source_File_Name, which provides handling for any possible naming
> scheme you can conceive.

Is that a challenge?!

Re: The Dreaded "Missing Subunits"

[Chad R. Meiners]

"Emmanuel Briot" <briot@act-europe.fr> wrote in message
news:m3bs7244yk.fsf@lyon.act-europe.fr...

> This is of course wrong. Have a look in the documentation at pragma
> Source_File_Name, which provides handling for any possible naming scheme
you
> can conceive.

For a brief second I thought Robert Dewar had returned ;)

-CRM

Re: The Dreaded "Missing Subunits"

[Robert A Duff]

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

> Peter Amey <peter.amey@praxis-cs.co.uk> writes:
> 
> > Are you really using the GNAT compiler with Rational naming
> > conventions?  I don't know if that is the cause of your problem but it
> > certainly won't help.  Rational (rather bizarrely in my view) use
> > xxx.1.ada for specs and xxx.2.ada for bodies.

I'm not sure why Peter thinks this convention is bizarre.  In fact, it
has some nice properties.  I think the Rational convention is quite
rational indeed.  For example a simple wildcard can be use to select
interesting files, like "all the Ada source code in this directory",
"all the specs", "all the bodies", "the spec of package X and all its
children", "the specs and bodies of X and all its children".  And when
you list them in alphabetical order they come out in a sensible order
(specs before bodies, parents before children).  So for example if I
print out "*.ada" I get a stack of paper in a sensible order for
reading.  With the GNAT convention, things come out in the wrong order.

>...  The GNAT convention
> > (which automates builds) is to use:
> > 
> > unit_name.ads for specs, unit_name.adb for bodies and
> > grandparent-parent-unit_name.adb for subunits.
> 
> This is of course wrong. 

True.  GNAT can be told to use the Rational convention, and works just
fine.

However,...

>...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.

The sad thing is that although Ada is very portable in many respects,
the community of compiler vendors can't agree on file-naming
conventions.  Contrast with C, where everybody knows what .h and .c
mean.

- Bob

Re: The Dreaded "Missing Subunits"

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> The sad thing is that although Ada is very portable in many
> respects, the community of compiler vendors can't agree on
> file-naming conventions.  Contrast with C, where everybody knows
> what .h and .c mean.

Is this a joke? cos it's clear that .h and .c have absolutely _no_
semantic content! (except, I suppose, that a compiler knows it's not
sensible to compile a header on its own ..

   smaug[11]$ gcc -c cpu_private.h   
   gcc: Compilation of header file requested

)

Re: The Dreaded "Missing Subunits"

[Ted Dennison]

Simon Wright <simon@pushface.org> wrote in message news:<x7vu1kss4q2.fsf@pushface.org>...
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > The sad thing is that although Ada is very portable in many
> > respects, the community of compiler vendors can't agree on
> > file-naming conventions.  Contrast with C, where everybody knows
> > what .h and .c mean.
> 
> Is this a joke? cos it's clear that .h and .c have absolutely _no_
> semantic content! (except, I suppose, that a compiler knows it's not

It must be. The problem is that most folks *think* they know what
those extensions mean, but the compiler could care less what you
think.

For instance, Tornado (the vxWorks development enviroment) comes with
quite a few .c files that are "#include"d rather than compiled. Good
luck figuring that out!

And of course most folks feel that C++ should have its own extensions,
but there is little agreement on what they should be. ".cpp" seems
common, but I've also seen ".C" and ".cc". The extension ".c" is
sometimes used to mean code that is purposely C compatable, while
sometimes its used for C++-only files. For headers I've seen
personally or seen suggested ".h", ".hpp", ".d", "..c", ".hh", and
".icc" (for inline header files). The C++ standard itself specifies
that quite a few header files have no extension at all!

Of course no matter what you use, the compiler won't care a bit, and
will happily include a ".cpp" or compile a ".hpp", if you tell it to
and the syntax passes.

References: http://www.cs.umd.edu/users/cml/cstyle/

Re: The Dreaded "Missing Subunits"

[Keith Thompson]

dennison@telepath.com (Ted Dennison) writes:
[...]
> And of course most folks feel that C++ should have its own extensions,
> but there is little agreement on what they should be. ".cpp" seems
> common, but I've also seen ".C" and ".cc". The extension ".c" is
> sometimes used to mean code that is purposely C compatable, while
> sometimes its used for C++-only files. For headers I've seen
> personally or seen suggested ".h", ".hpp", ".d", "..c", ".hh", and
> ".icc" (for inline header files). The C++ standard itself specifies
> that quite a few header files have no extension at all!

Actually, it specifies that quite a few *headers*, not necessarily
header files, have no extension.  There's no requirement that the
predefined headers be implemented as files; even if they are, there's
no required correlation between the names used in the "#include"
directive and the actual names of the files.

> Of course no matter what you use, the compiler won't care a bit, and
> will happily include a ".cpp" or compile a ".hpp", if you tell it to
> and the syntax passes.

At least for C, there's no language requirement for any particular
filename extensions, but there's a very strong convention that header
files are *.h and other source files are *.c.  (No, that convention
isn't always honored, but I rarely see exceptions.)

The source file naming situation for C++ and Ada actually seems pretty
similar.  The C and Ada file naming conventions are also pretty
similar, except that C's conventions are more consistent.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: The Dreaded "Missing Subunits"

[Ted Dennison]

Keith Thompson wrote:
> The source file naming situation for C++ and Ada actually seems pretty

Very generally, I'd agree. However, I'd say C++ multiplies the problem 
quite a bit due to several factors.

For one thing, there are 3 types of files rather than 2: includes, code, 
and inline includes (or there are 2 or 4 types, depending on who you 
talk to). Also C++ compilers almost never try to enforce or encourage 
one standard or another. Build tools do sometimes encourage a subset, 
but rarely one particular scheme. So its generally up to the whims of 
the developers rather than the compiler toolkit designers. There are a 
whole lot more developers than there are compiler vendors, so this 
amounts to a conucopia of different file extension schemes one has to be 
prepared to deal with. Also this means that knowing what compiler you 
are using is no help.

> similar.  The C and Ada file naming conventions are also pretty
> similar, except that C's conventions are more consistent.

That depends on what you mean by "consistent". Across all compilers: 
yes. Within a single compilation enviroment: usually not.

It should also be noted that even where C is *more* consistent, it still 
isn't consistent. File name and directory path issues can still throw 
you off, and there are people (typically well out of baseball bat reach) 
who don't follow the standard. Few compilers try to enforce it, so like 
much of C, it is really only a standard in peoples' minds.

But without these Zen-like qualities, it just wouldn't be the C we all 
know and love, would it? :-)

Re: The Dreaded "Missing Subunits"

[Robert A Duff]

dennison@telepath.com (Ted Dennison) writes:

> Simon Wright <simon@pushface.org> wrote in message news:<x7vu1kss4q2.fsf@pushface.org>...
> > Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > 
> > > The sad thing is that although Ada is very portable in many
> > > respects, the community of compiler vendors can't agree on
> > > file-naming conventions.  Contrast with C, where everybody knows
> > > what .h and .c mean.
> > 
> > Is this a joke?

No, I wasn't joking.

>... cos it's clear that .h and .c have absolutely _no_
> > semantic content!

Sure they do -- to programmers.  The "semantic content" is merely a
convention, not enforced by compilers.  But that's OK -- at least
you can write a bunch of .c and .h files, using the normal convention,
and expect it to compile using *any* C compiler.

I realize that in rare cases, C programmers violate the convention.
But these cases are very rare indeed, in my experience.

Contrast with Ada, where GNAT wants .ads/.adb, Rational wants
.1.ada/.2.ada, and AdaMagic wants .spc/.bdy.  I know GNAT and AdaMagic
have ways of overriding the convention (not sure about Rational),
but you have to go to extra trouble to use a convention different
from what the compiler wants.  Wouldn't it be better if all Ada
compilers supported the same file-naming conventions out of the box,
without using nonstandard pragmas Source_File_Name and the like?

What file-naming convention should I use, if I want to be
portable across all compilers?  For C, the answer is easy.
For Ada, it's not.

> It must be. The problem is that most folks *think* they know what
> those extensions mean, but the compiler could care less what you
> think.

But *all* C compilers are capable of compiling C programs consisting of
the usual .c and .h files, without any extra trouble.

> For instance, Tornado (the vxWorks development enviroment) comes with
> quite a few .c files that are "#include"d rather than compiled. Good
> luck figuring that out!

Beside the point.

> And of course most folks feel that C++ should have its own extensions,
> but there is little agreement on what they should be.

Yes, but I hope you're not one of those folks who think C/C++ is a
language.  ;-)  C and C++ do share some problems.  (As one of the
designers who turned Ada 83 into Ada 95, I feel some kinship with Bjarne
Stroustrup!  Upward compatibility is not easy.)  But for this particular
issue, C wins (even though the convention is "merely" a cultural
convention, and is sometimes violated) -- *I* didn't mention C++.

>... ".cpp" seems
> common, but I've also seen ".C" and ".cc". The extension ".c" is
> sometimes used to mean code that is purposely C compatable, while
> sometimes its used for C++-only files. For headers I've seen
> personally or seen suggested ".h", ".hpp", ".d", "..c", ".hh", and
> ".icc" (for inline header files). The C++ standard itself specifies
> that quite a few header files have no extension at all!
> 
> Of course no matter what you use, the compiler won't care a bit, and
> will happily include a ".cpp" or compile a ".hpp", if you tell it to
> and the syntax passes.

I guess that's my point: most Ada compilers *do* care, and they favor
*different* conventions.  At least in C++ you can *choose* some
convention that works easily on all compilers.

> References: http://www.cs.umd.edu/users/cml/cstyle/

- Bob

Re: The Dreaded "Missing Subunits"

[Emmanuel Briot]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Contrast with Ada, where GNAT wants .ads/.adb, Rational wants
> .1.ada/.2.ada, and AdaMagic wants .spc/.bdy.  I know GNAT and AdaMagic
> have ways of overriding the convention (not sure about Rational),
> but you have to go to extra trouble to use a convention different
> from what the compiler wants.  Wouldn't it be better if all Ada
> compilers supported the same file-naming conventions out of the box,
> without using nonstandard pragmas Source_File_Name and the like?


The reason things are different for Ada are related to Ada itself. In C, you do
a #include with a file name, in Ada you do it with a unit name. So the compiler
has to be able to find the matching file.

If you take the simpler case of a file not having any dependency (say other
than the run time), you can compile it whatever its name and without specifying
a convention:
    gcc -x ada  my_file.foo

The make-like utilities (gnatmake for GNAT) also need to have access to all the
sources in your application. In C, you specify explicitely the list of
dependencies in a Makefile (I know you can use "make dep", but then with GNAT
you can use "gnatname", and that's the same).

Given all this, I don't see the difference. You have to do at least as much
work when programming in C. And maintaining the Makefiles can really be a pain,
as people who have worked on big projects will know.

Emmanuel

Re: The Dreaded "Missing Subunits"

[Preben Randhol]

On Wed, 18 Sep 2002 20:56:18 GMT, Robert A Duff wrote:
> Contrast with Ada, where GNAT wants .ads/.adb, Rational wants
> .1.ada/.2.ada, and AdaMagic wants .spc/.bdy.  I know GNAT and AdaMagic
> have ways of overriding the convention (not sure about Rational),
> but you have to go to extra trouble to use a convention different
> from what the compiler wants.  Wouldn't it be better if all Ada
> compilers supported the same file-naming conventions out of the box,
> without using nonstandard pragmas Source_File_Name and the like?
> 
> What file-naming convention should I use, if I want to be
> portable across all compilers?  For C, the answer is easy.
> For Ada, it's not.

Well first you have to ensure that your source code *IS* portable to any
compiler, second it is not rocket-science to make a simple script to
rename the files depending on which compiler one has. Of course with
nice user-friendly Windows this is less easy because it is so user
friendly.

But that people get so worked up of simple name conventions sure signals
that they need to fill their time with coding ;-) I could need a nice
project planner in Ada with GtkAda GUI under GMGPL/GPL/BSD license. Any
takers ;-)

Preben

Re: The Dreaded "Missing Subunits"

[Marc A. Criley]

Robert A Duff wrote:
> 
> dennison@telepath.com (Ted Dennison) writes:
> 
> > Simon Wright <simon@pushface.org> wrote in message news:<x7vu1kss4q2.fsf@pushface.org>...
> > > Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > >
> > > > The sad thing is that although Ada is very portable in many
> > > > respects, the community of compiler vendors can't agree on
> > > > file-naming conventions.  Contrast with C, where everybody knows
> > > > what .h and .c mean.
> > >
> > > Is this a joke?
> 
> No, I wasn't joking.
> 
> >... cos it's clear that .h and .c have absolutely _no_
> > > semantic content!
> 
> Sure they do -- to programmers.  The "semantic content" is merely a
> convention, not enforced by compilers.  But that's OK -- at least
> you can write a bunch of .c and .h files, using the normal convention,
> and expect it to compile using *any* C compiler.

But contrast with C++ as well, where I've encountered both .h and .hh
for header files, and .cc, .cpp, .cp, and .cxx for source files.  Why
can't the C++ community agree on a file-naming convention?  (Note that
.h is ambiguous, since it's commonly used for both C and C++, and
obviously a .h file containing a class will not be compilable by a C
compiler.)

Marc A. Criley

Re: The Dreaded "Missing Subunits"

[Marin David Condic]

Here's a better idea than a file extension convention: Why not have all Ada
compilers allow the user to specify what the convention is for their
project? Most of the compilers I've seen have some ability already to store
configuration or initialization information in some manner. If its a
command-line compiler (id est, Gnat) it could be a switch set by the IDE or
there can be some special file for a project that identifies the convention
as well as other useful initialization & option stuff.

It may be handy from some kind of portability perspective or user
recognition perspective if everyone used the same filename extension to mean
the same thing, but I don't think its that necessary. An OS might not even
make much or any use of the extension to begin with, so for a given
implementation, it might not make much sense anyway. If the world can agree
on what the file name convention should be, fine. If not, the vendors need
only provide some reasonably easy means of specifying what the convention is
for a project and most of the problems go away.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message
news:wccptvb9fv1.fsf@shell01.TheWorld.com...
>
> Contrast with Ada, where GNAT wants .ads/.adb, Rational wants
> .1.ada/.2.ada, and AdaMagic wants .spc/.bdy.  I know GNAT and AdaMagic
> have ways of overriding the convention (not sure about Rational),
> but you have to go to extra trouble to use a convention different
> from what the compiler wants.  Wouldn't it be better if all Ada
> compilers supported the same file-naming conventions out of the box,
> without using nonstandard pragmas Source_File_Name and the like?
>
> What file-naming convention should I use, if I want to be
> portable across all compilers?  For C, the answer is easy.
> For Ada, it's not.
>

Re: The Dreaded "Missing Subunits"

[Dmitry A.Kazakov]

Robert A Duff wrote:

> Contrast with Ada, where GNAT wants .ads/.adb, Rational wants
> .1.ada/.2.ada, and AdaMagic wants .spc/.bdy.  I know GNAT and AdaMagic
> have ways of overriding the convention (not sure about Rational),
> but you have to go to extra trouble to use a convention different
> from what the compiler wants.  Wouldn't it be better if all Ada
> compilers supported the same file-naming conventions out of the box,
> without using nonstandard pragmas Source_File_Name and the like?

Can somebody explain why those nasty .ads/.adb appeared? Is that a big deal 
to detect the word "body" in the source code? Why files cannot be just 
.ada? If I wish to separate specifications and bodies, well, since RSX-11M 
all operating systems have subfolders...

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: The Dreaded "Missing Subunits"

[Preben Randhol]

On Thu, 19 Sep 2002 23:49:06 +0200, Dmitry A.Kazakov wrote:
> Can somebody explain why those nasty .ads/.adb appeared? Is that a big deal 
> to detect the word "body" in the source code? Why files cannot be just 
> .ada? If I wish to separate specifications and bodies, well, since RSX-11M 
> all operating systems have subfolders...

Come on what is so nasty with .adb .ads? I find it easier to read .ads
files in order to see which functions/procedures the package provides.
If you have a .ada file you will have to jump up and down a lot. Besides
don't you get the with-ing problem with .ada?

Preben

Re: The Dreaded "Missing Subunits"

[Dmitry A.Kazakov]

Preben Randhol wrote:

> On Thu, 19 Sep 2002 23:49:06 +0200, Dmitry A.Kazakov wrote:

>> Can somebody explain why those nasty .ads/.adb appeared? Is that a big
>> deal to detect the word "body" in the source code? Why files cannot be
>> just .ada? If I wish to separate specifications and bodies, well, since
>> RSX-11M all operating systems have subfolders...
> 
> Come on what is so nasty with .adb .ads?

Not so nasty if you start a new project. But I remember how it took two 
days or so to rename all files while porting a project from DEC Ada to 
GNAT. It was not only file extensions. For the sake of portability all 
files names were 8-letters long. Well, it appeared a little bit less 
portable than we expected! (:-))

> I find it easier to read .ads
> files in order to see which functions/procedures the package provides.
> If you have a .ada file you will have to jump up and down a lot.

True, but in a medium-sized project it becomes either disastrous. Good 
navigation tools and IDE are indispensable. 

> Besides don't you get the with-ing problem with .ada?

Why? It worked with Ada 83, why shouldn't it with Ada 95.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: The Dreaded "Missing Subunits"

[Stephen Leake]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:

> Preben Randhol wrote:
> > Come on what is so nasty with .adb .ads?
> 
> Not so nasty if you start a new project. But I remember how it took two 
> days or so to rename all files while porting a project from DEC Ada to 
> GNAT. It was not only file extensions. For the sake of portability all 
> files names were 8-letters long. Well, it appeared a little bit less 
> portable than we expected! (:-))

gnatchop would solve that problem easily; perhaps it was not available
then.

It would be nice if every vendor provided a similar tool; "take this
collection of randomly named files and name them according to your
convention". 

> > Besides don't you get the with-ing problem with .ada?

Depends on wether the spec and body are both in one file, or you still
have two files, just both ending in .ada.

If you have two files, then you still need some convention to
distinguish the body from the spec; hence Rationals foo.1.ada,
foo.2.ada.

If you have one file, you lose the separate compilation of spec and
body. You don't get horrible "withing" problems (Ada is still the same
language), you just get horrible recompilation times (you recompile
the spec and everything that depends on it, every time you change the
body).

> Why? It worked with Ada 83, why shouldn't it with Ada 95.

In Ada 83 you still needed different file names for the spec and body.
The convention I used with DEC 83 (if I recall correctly) was
foo_s.ada for the spec, and foo.ada for the body. I much prefer
foo.ads, foo.adb.

You could put both spec and body in one file, but you got the same
horrible recompilation issues.

-- 
-- Stephe

Re: The Dreaded "Missing Subunits"

[Preben Randhol]

On Fri, 20 Sep 2002 04:42:36 +0200, Dmitry A.Kazakov wrote:
> Preben Randhol wrote:
> 
> Not so nasty if you start a new project. But I remember how it took two 
> days or so to rename all files while porting a project from DEC Ada to 
> GNAT. It was not only file extensions. For the sake of portability all 
> files names were 8-letters long. Well, it appeared a little bit less 
> portable than we expected! (:-))

Well you don't have to worry about 8-letters and converting the file
names takes max 5 minutes on a user friendly OS.

>> Besides don't you get the with-ing problem with .ada?
> 
> Why? It worked with Ada 83, why shouldn't it with Ada 95.

I don't know how the .ada works, but sometimes you have to with in the
.adb and not the .ads to avoid circular dependance. But I guess you can
put the withs after the spec and the compiler will recognice this?

Anyway I still think it is clearer to have the .ads files for looking at
what a package provides. Besides you should also put your documentation
here that has to do with the usage of the procedures/functions. As to
big systems, do the packages become huge too or is it only that there a
lot of them?

Preben

Re: The Dreaded "Missing Subunits"

[Dmitry A.Kazakov]

Preben Randhol wrote:

> Anyway I still think it is clearer to have the .ads files for looking at
> what a package provides. Besides you should also put your documentation
> here that has to do with the usage of the procedures/functions. As to
> big systems, do the packages become huge too or is it only that there a
> lot of them?

There are many packages. Then if the software has to be portable, some of 
them have many platform-dependent bodies ("second axis"). Then there are 
packages providing abstract base types user-derived ones. The packages 
implementing that user-derived types ("third axis") multiply like flies 
(:-)). It is simply impossible to keep all that exploding stuff in one 
folder. But when you start to use subfolders then it is usually better to 
have one folder tree for specifications and another for implementations. So 
the file names never clash.

For beginners and in classes it is easier to have an ability to put several 
compilation units in one file. Later on one can explain students that it is 
a bad praxis. (:-))

Maybe .ads, .adb are not so bad, I just suspect that they can much help 
in solving code management problems.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: The Dreaded "Missing Subunits"

[Emmanuel Briot]

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.

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.

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.

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

Re: The Dreaded "Missing Subunits"

[Robert A Duff]

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

Re: The Dreaded "Missing Subunits"

[Stephen Leake]

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). 

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

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.

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.

> 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.

> (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.

> 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

Re: The Dreaded "Missing Subunits"

[Robert A Duff]

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

Re: The Dreaded "Missing Subunits"

[Keith Thompson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> > Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > > (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.

And eminently fixable, if the ACT folks care to do it.

In the meantime, it shouldn't be too difficult to run a script over
the source directories that creates symbolic links with the full
names.  (Yes, I'm assuming a Unix-like environment.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: The Dreaded "Missing Subunits"

[Stephen Leake]

Keith Thompson <kst@cts.com> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> > > Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > > > (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.
> 
> And eminently fixable, if the ACT folks care to do it.
> 
> In the meantime, it shouldn't be too difficult to run a script over
> the source directories that creates symbolic links with the full
> names.  (Yes, I'm assuming a Unix-like environment.)

I had hoped gnatchop would do exactly that, since that's what it does
for "normal" code. But apparently gnatchop has the System and Ada
packages hardcoded as special cases, because it produced the same 8.3
file names.

One of these days, I'll get the source for gnatchop, and take out the
hardcoding. In the meantime, I just cope.

Actually, Emacs ada-mode has an interface to gnatchop, so if I put the
cursor on 'with Ada.Text_IO', and hit a key, it knows how to find the
8.3 filename. That helps a lot.

-- 
-- Stephe

Re: The Dreaded "Missing Subunits"

[Larry Kilgallen]

In article <wccfzw6n914.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> 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.

Perhaps I misunderstand the question, but I thought that is what
DEC Ada (83) does (pay attention only to the files the OS says
have been changed).  Or is DEC Ada excluded because the checking
is done by the ACS program that drives the compiler rather than
by the compiler itself ?

Re: The Dreaded "Missing Subunits"

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> 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.

Yes, using cached data. Sounds pretty good.

> > 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.

Well, we could argue about that. You have to build the cache once
before you realize the speed gain. 

The distinction I'm making is between "source based" as in GNAT, and
"library based" as in DEC Ada 83. I suggest that your system is
somewhere in between; there is a "library" that has knowledge about
the compilation environment. It is lightweight compared to the DEC Ada
83 library, but it is more than plain GNAT requires. Although, even
GNAT uses the existing .ali files to speed things up. I guess there
are no "pure" systems :).

> > 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.

Ok, that makes sense.

-- 
-- Stephe

Re: The Dreaded "Missing Subunits"

[Randy Brukardt]

Robert A Duff wrote in message ...

>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.


Careful! Don't assume that these steps are faster than just parsing the
file. When we were (re)designing our make tool, we found that reading a
timestamp took about the same amount of time as parsing 500 lines of a
file (this was on MS-DOS/Windows 95, I think). Moreover, saving the
gathered information on disk was complex enough that it cost the same as
parsing another 1000 lines of a file. Not many Ada files are bigger than
1500 lines. So we don't even try to save information about source files;
reparsing and rebuilding the information in memory is generally faster.

This is essentially the basis of Xtreme Programming, after all: don't
build something complex until you've proven that the simple version is
too slow. (Just another piece of common sense that someone is making a
lot of money selling to people without it.)

         Randy Brukardt

Re: The Dreaded "Missing Subunits"

[Peter Richtmyer]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccn0qf9evb.fsf@shell01.TheWorld.com>...

> 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).
> 

Some years ago I wrote a perl script to do just that. Seems to me it
is now obsolete since we can use wildcards in the pragma. But here's
the "help" from the utility (abbreviated a bit - took out some
project-specific info).
I can forward the script to anyone who wants it. 

    ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

                     make_gnat_adc.pl                               

       make_gnat_adc.pl  [-v] [-e] [-a]  [I/path/dir]...  
    or
       make_gnat_adc.pl  [-h]

    This utility will create a 'gnat.adc' file in the current
directory.
    The file will contain 'Source_File_Name' pragmas for all
Apex-formatted
    Ada files in the specified 'paths'. These pragmas are for use by
the Gnat
    Ada compiler, so that it can convert each Ada program 'unit' name
into an
    Apex Ada File name. Once the compiler knows the file name, it can
    search for the correct file to compile.            

    The 'gnat.adc' file must be in the directory from which the
compile
    is run. And this one gnat.adc file must contain pragmas for all
for
    all Ada source files needed that are not in the standard Gnat
format.

    The 'paths' may come from any or all of these sources:           
        1) Environment variable ADA_INCLUDE_PATH. This is a standard
           Gnat variable that can contain multiple directories,
separated
           by '$SEPARATOR'. Gnat uses this path when searching for Ada
program
           units.                          
        2) 'path' string(s) on the command line. They are entered
after
           the -I option. Similar to the "-I" option for gnatmake, but
it
           can contain one or directories, separated by '$SEPARATOR'.
      
     Each option string must start with a '-'. Options are:
        'v'  or 'V' - Verbose mode - Print debugging-level details.
                      Default is no details.             
        'e'  or 'E' - Use the Environment variable ADA_INCLUDE_PATH. 
                      The default is to not use it.     
        'a' or 'A'  - Use the directory that is the same name as the
current
                      directory except that it does not have "/proj"
at the
                      beginning.
        'h'  or 'H' - Help. Print this Help and halt. Default is no
Help.
        'Ipath/dir' - A directory to be searched for Ada files. Or
more than
                      one directory, separated by the '$SEPARATOR'.
the
                      Separator character is dependant upon the
operating
                      system, where:
                             Windows -> ';'
                             Unix    -> ':'
   
     The options may be separate (e.g.: "-v -e -I/temp -I/temp2"), or
may be combined
     (e.g.:  "-veI/temp -I/temp2").                        

     The pragma format is:
         Source_File_Name (Unit_Name =>      unit-name,
                           Spec_File_Name => "spec-file-name");
     or
         Source_File_Name (Unit_Name =>      unit-name,
                           Body_File_Name => "body-file-name");
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Peter

Re: The Dreaded "Missing Subunits"

[Randy Brukardt]

Robert A Duff wrote in message ...

>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?


Janus/Ada essentially does this. But there is a chicken & egg problem.

The Janus/Ada compiler doesn't care about naming conventions; only the
make tool does. To help out the make tool, the compiler stores the
source file names in the project when they are compiled. So, you can use
any naming you want, and makes will work fine without any user
intervention.

The problem is the first compile for a piece of source. You can tell the
make tool the naming convention you are using (within limits), but you
have to tell the make tool any names that don't match the convention.
That can get old when someone sends a bunch of files as a bug report
without any obvious naming convention (such as the 8 character
abbreviations noted earlier).

One way to reduce this problem is to integrate this with the IDE (which
is what Rational does, and what we'll do when (if ever) we rewrite the
IDE). But I don't think it can be solved in general.

>Furthermore, none of this mumbo-jumbo would be necessary at all,
>if only all Ada compilers agreed on the file naming convention.

I think that GNAT naming has become a de-facto standard, in that much of
the code that you get is in that format. If you can't handle it, you get
complaints from your customers. (Perhaps other vendors mileage may
vary.)

             Randy Brukardt

Re: The Dreaded "Missing Subunits"

[Mark Johnson]

Peter Richtmyer wrote:
> 
> I love the Gnat compiler but...
> 
>    I dread this error message:
> 
>    "No code generated for file xxxx.2.ada (missing subunits)"
> 
> It means that I have a procedure or function declared "...is separate;"
> in package xxxx, but there is no matching separate.
Do you mean the separate doesn't exist or that it does not have the
"right filename"? I will assume the latter.

> A "legacy" package
> has a gazillion separates. They need changes, and the calling
> parameters get changed and don't match, or the routine name changes,
> or the separate filename isn't right, or whatever happens to get this
> message, and it is a real pain to figure out which "subunit" is missing.
> 
I doubt these are causes of the error message.

> Anybody have a solution? maybe a compile switch or ...?
> 
What we use for code we ported from a rational system is...

  pragma Source_File_Name (Spec_File_Name => "*.1.ada");
  pragma Source_File_Name (Body_File_Name => "*.2.ada");

These configuration pragmas should be in a file named gnat.adc (along
with any other pragmas you may want to apply to every compilation). This
is documented in both the GNAT User's Guide and Reference Manuals. In
the User's Guide, look for sections titled "Configuration Pragmas",
"Using Other File Names", and "Alternative File Naming Schemes". In the
Reference Manual, look for the "Implementation Defined Pragmas" section
and search for Source_File_Name.

If you have an old version of GNAT that doesn't allow star names in this
pragma - I suggest you get a newer version.

If you have a large system with lots of directories, I can make some
suggestions on organizing the build so it may work a little easier as
well (and leverage data from the Apex configuration files that you may
have).

I suggest you take the time to read the user's guide and reference
manual in their entirety. You will learn a lot about the GNAT product by
doing so.

  --Mark

Re: The Dreaded "Missing Subunits"

[Stephen Leake]

prichtmyer@yahoo.com (Peter Richtmyer) writes:

> I love the Gnat compiler but...
> 
>    I dread this error message:
> 
>    "No code generated for file xxxx.2.ada (missing subunits)"
> 
> It means that I have a procedure or function declared "...is separate;"
> in package xxxx, but there is no matching separate. A "legacy" package 
> has a gazillion separates. They need changes, and the calling 
> parameters get changed and don't match, or the routine name changes, 
> or the separate filename isn't right, or whatever happens to get this 
> message, and it is a real pain to figure out which "subunit" is missing.
> 
> Anybody have a solution? maybe a compile switch or ...?

This is clearly a non-helpful error message; it should give the file
names and/or subunit names. 

Actually, did you try the compiler switch -gnatf? That might help (I
don't use subunits, so I don't know).

Send a request to report@gnat.com. If you are a paying customer,
they'll give it more weight.

-- 
-- Stephe

Re: The Dreaded "Missing Subunits"

[Simon Wright]

I just tried this with GCC-3.2:

   procedure Sep is
      procedure Ch is separate;
   begin
      Ch;
   end Sep;

and get

   smaug[9]$ gnatmake sep
   gcc -c sep.adb
   No code generated for file sep.adb (missing subunits)
   sep.adb:2:04: warning: subunit "Sep.Ch" in file "sep-ch.adb" not found
   gnatmake: "sep.adb" compilation error

Which version are you using?

Re: The Dreaded "Missing Subunits"

[Peter Richtmyer]

Simon Wright <simon@pushface.org> wrote in message news:<x7vy9a5d2t2.fsf@pushface.org>...
> I just tried this with GCC-3.2:
> 
>    procedure Sep is
>       procedure Ch is separate;
>    begin
>       Ch;
>    end Sep;
> 
> and get
> 
>    smaug[9]$ gnatmake sep
>    gcc -c sep.adb
>    No code generated for file sep.adb (missing subunits)
>    sep.adb:2:04: warning: subunit "Sep.Ch" in file "sep-ch.adb" not found
>    gnatmake: "sep.adb" compilation error
> 
> Which version are you using?

I (the original poster) am using Gnat 3.14P on Win2K and AdaGIDE.

When I build your little sample above, I get the same (helpful) error
message. 

It seems to have something to do with the fact that we are not using the
.ads and .adb extensions. We do use the Source_File_Name pragmas.

the end of the error message (directory and unit names changed):

-------------------------------------
gcc -c -Ic:\yyyyyy\sw\xxxx\ -gnatwu -gnato -IC:\YYYYYY\sw\XXXX -I.\. 
-I.\.. -I.\changes -I..\changes -I.\hacks -x ada -gnatwl -gnatws -gnatf -
g -I- -x ada -o .\changes\zzzz.2.o .\changes\zzzz.2.ada
No code generated for file zzzz.2.ada (missing subunits)
End of compilation
gnatmake: ".\changes\zzzz.2.ada" compilation error
Done--error detected.
-------------------------------------

I created a small test package with the .ads and .adb extensions 
and I got the name of the missing unit in the error mmessage. Of course,
my "real" problem package is much larger, but that should not make a 
difference.

I'll Take Stephen Leake's advice and report it. 
See what the doctor says.  :-)

Thanks to all...
Peter

Re: The Dreaded "Missing Subunits"

[Brian Gaffney]

prichtmyer@yahoo.com (Peter Richtmyer) wrote in message news:<1b585154.0209160928.1381657a@posting.google.com>...
...
> I (the original poster) am using Gnat 3.14P on Win2K and AdaGIDE.
> 
> When I build your little sample above, I get the same (helpful) error
> message. 
> 
> It seems to have something to do with the fact that we are not using the
> .ads and .adb extensions. We do use the Source_File_Name pragmas.
> 

Is there some reason you need to keep the original naming scheme?

If not, you could do something like (I'm not sure it would run this
way, but you get the idea):

gnatchop *.ada GNAT_Files

This will create a new set of files in directory GNAT_Files (or
whatever) that all use the GNAT naming scheme.

Re: Ada2005 temp solo child (was: Re: The Dreaded "Missing Subunits"

[Grein, Christoph]

> While developing an application, I have e.g. a parent.child
> but not yet a parent package, which may or may come later.
> Now my compiler forces me to have the parent.
> I would prefer the ada standard would force the compiler
> to allow parentless children.
> Did I ignore some important aspect?

I do not know, but the request seems silly to me. Why is it so disturbing to create a 
dummy parent, which is still empty. It has to be created anyway eventually, so 
why not just now? If there will never be a parent, why have the hierarchy at 
all?