[Emacs-ada-mode] Emacs ada-mode gpr management

[Stephen Leake]

David Sauvage <sauvage.david at gmail.com> writes:

>>> I've created gnatgpr for another project [3],  and i then discover it
>>> could really  satisfy the emacs ada-mode needs .
>>>     
>>
>> Almost. Emacs Ada mode needs the list of source directories and object
>> directories. 

> Well, at first i though Emacs Ada mode would like to know about (for
> example)
> Excluded_Source_Files, Source_Files, Source_File_Dirs, but ok.

It might be useful in the future to use these extended features, but
they are not used now.

I forgot to mention; Emacs Ada mode also needs the lists of compiler
runtime source and object directories.

If you do 'gnat list -v -P<project>', Emacs Ada mode needs the Source
Search Path and Object Search Path lists.

>> Ah; I see in your README that you do support GPL 2007 and Pro 6.1.2. I
>> suggest you put that on the web page; it's critical information.
>>   
>
> In the main web page, see section "GNATGPR Available compilers & platforms".

Sorry, I missed that (I was in too much of a hurry). 

Although I was confused by "GNATGPR is based on GNAT GPL 2008". I
guess that means "GNATGPR implements the gpr facility as defined by
GNAT GPL 2008". Perhaps you could make that clearer.

>> Why do you say gnatgpr is "GNAT dependent"? Just "with GNAT.OS_Lib",
>> or more than that? 
> I only say it because i think it would not compile with another Ada
> compiler.
>
> with GNAT.Case_Util
> with GNAT.Directory_Operations
> with GNAT.Dynamic_HTables
> with GNAT.Dynamic_Tables
> with GNAT.HTable
> with GNAT.OS_Lib
> with GNAT.Spelling_Checker
> with GNAT.Strings
> with GNAT.String_Split
>

Ok. I suggest you add "uses GNAT-specific packages" to that line on
the web page.

>> In general, non-gnat systems might benefit from gpr
>> files.
>>   
> Sure, by using gnatgpr we already use gpr project files for non-gnat
> systems

Right. But if gnatgpr compiled with another compiler, they wouldn't
need the gnat compiler at all. That would be slightly simpler.

Although in my experience (not very recent; I'm only using gnat these
days), I like the gnat error messages _much_ better than other
compilers, so I'd compile with gnat first, before attempting to
compile with another compiler.

> i know some guys how have built and use it on windows platform with
> sucess ...

I just compiled on Windows; it only needed 'make gnatgpr'. gnatmake is
wonderful :).

However, the resulting executable is broken. It produces no output.
I'll see if I can run it in the debugger ... no, that doesn't work; I
don't think the Windows debugger can debug dynamic libraries.

So I created a new gnatgpr_static.gpr that flattens all your project
files, and builds a static image. That generated some warnings; I
guess fixing them would diverge farther from AdaCore sources. And it
hangs when compiling namet_gnatgpr.adb! arrggghh!

So I simplified the compiler options, and now it compiles.

The problem was I was specifying the project file wrong; I used
"-Pgds_test.gpr" as gnat wants, but gnatgpr wants "-p gds_test.gpr".
Apparently the error reporting is broken on Windows with dynamic
libraries. It works on Debian, and with static linking on Windows.

Anyway, I got gnatgpr to run on Windows. As I suspected, it is _not_
significantly faster than 'gnat list -v'. 

My Debian box is really fast in general, so it's not a good platform
for comparing speed :(.

All this has made me think more about how Emacs Ada mode uses 'gnat
list', and I think I'm calling it more often than I need to. So this
conversation will result in an increase in speed anyway :).

I just realized that one reason things are faster now is that AdaCore
changed the output of 'gnat list -v'; in 5.04, it output details on
each object file. In 6.2.1, it only outputs the paths, which saves a
lot of time. 

So much for Emacs Ada mode relying on "standard behavior" !

(next email):

>> Well, my proposition is to help you on the gnatgpr integration, by
>> working on the gnatgpr side.
>> What  i then propose you is :
>>        gnatgpr -[n]sd <project file>
>>                   Display all included source directories.
>>                   Non-transitive analysis if n option is given.
>>   
> I just published gnatgpr 0.25 that implement this service.

Ok, that's good, and it works on Debian. 

But given the above speed result, I don't think this is worth
persuing. Unless you have some ideas for making this faster. 

I think most of the time is spent reading directories and/or files;
'gnat list' is significantly faster the second time it is run (as is
gnatgpr), when the disk cache has all the right files in it. I'm
guessing it's checking all the .ali files, which is a waste of time
for this purpose.

-- 
-- Stephe