Re: chopping Ada source that have preprocessor symbols in them

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 16.02.13 09:22, Stephen Leake wrote:

> I gather you believe changing the procedures in the foreign organization
> is impossible; have you at least asked? Explained your problem and asked
> for solutions?

I have asked for why this arrangement of source code is needed; others
have asked before me. The reasons given are in fact convincing once
the context becomes apparent to the outsider.

> I don't see that as "abstracting files away"; C-c C-d (in Emacs Ada
> mode) navigates to another file. Files are quite central to editing in
> Emacs.

The programmer using an IDE does not have to remember the files, the
file naming scheme, etc.(*) Source code navigation and language-based
views give a better outline of the program's structure. Files are
central to how Emacs and other IDEs fill and save text buffers, sure,
but the files vanish when editing with good language support. "Get me
the declaration of that thing!" If this is what the programmers wish
the IDE to do for them, then why should they have to do all the name
resolution themselves? I.e. find full Ada names and then know the
corresponding file system names?

>> My fairly recent 4 core machine
>
> The disk speed, memory size, and CPU clock rate (in that order) have
> more impact; the gnat compiler does not take advantage of multiple cores
> (unless I've missed a recent change), and compiling does a lot of disk IO.

File I/O is not slowing the process much; what seems to matter is the
dependency mechanism that GNAT is using (which, I think, is normally
stat(2)-based).  This would be the reason why GNAT's switch -m helps
so much whenever it works with freshly chopped source.


> Yes, the details matter. Improving generic instantiation compilation
> speed might also be a reasonable enhancement request; AdaCore can always
> use more feedback on what to work on next.

In case of generic instantiations, I'd actually expect, or even hope
that compilation time increases. When the compiler spends time
handling instances this could reflect efforts to adapt instances to
the specifics of the generic formals.  Indeed, the quality of the code
produced lets me think that compilation time was well spent. I have
few compilers to compare, but for example, I see what happens to
statically known conditionals whose value depends on generic
formals---static polymorphism at its best, without the need for a
tagged dummy variable. This counts when inner loops perform no
comparison instead of an average of 2, so waiting for the compiler is
worth it. (That's assuming that the program would not work better
if all instances shared the same code of a smaller executable.)

__
(*) Maybe this is a reason why some programmers coming from Turbo
Pascal-like IDEs would have to learn about files, editors, command
line compilers etc. They had been developing software without these
artifacts of OS bureaucracy.