Re: seperate keyword and seperate compilation with Gnat?

[dewar@cs.nyu.edu (Robert Dewar)]

Michael said

"So, you don't consider me a customer anymore? :-) We talked about
precisely this issue at the GNAT workshop in Frankfurt last year.
The fact that GNAT does not compile subunits into separate object
files caused us some problems when we switched from Verdix to GNAT.
We have now restructured our code so this is not a big issue anymore,
but in order to save compilation time during developement it would
still be helpfull to have this feature. All of our examples are of
type 2 and if a separate code generation could be achieved easily
it would be nice to have but there are certainly more important
problems to be solved (e.g. a more efficent handling of unconstrained
arrays)."

Right, I know you mentioned this, but you also said that you could
restructure your code without any big problem (which I guess was
true :-)

However, what is really interesting, and what we did not discuss back
in Frankfurt was the distinction between type 1 and type 2. It is
VERY easy to allow separate compilation of type 2 subunits (those
nested inside packages), and in fact it is almost just a matter of
removing a restriction (well not quite a bit of binding trickery is
required), but it is really easy.

What I mean when I said no one had commented on it was that no one
had declared that this was a really hot issue, and that surprised me.
I thought we would run into at least some customers for whom this
would be a blocking problem.

Interestingly, I just talked with another customer, inspired to
think about the future by my post, who might be in exactly that
category, but there too, they are all type 2 (inside package)
cases and not the much more deadly type 1 (inside subprogram)
cases.

So the conclusion is that it definitely seems worth providing an
option to compile type 2 subunits separate (it can be an option,
so nothing will be lost if you want to do it the old way, which
is more efficient in compilation time if you are recompiling the
whole subtree).

Something to look into, probably not for the vesion immediately
coming out, but certainly for the vesion after that.

P.S. Having a close look at unconstrained arrays is getting near the
top of the priority list, so I think something will happen there
soon too (this is actually very target dependent, on some targets,
unconstrained arrays are handled fine, on others not. This results
from treating fat pointers as records.