Re: gps compile.

> You may think that this is not right at all, but it works pretty well.

Well, that's clearly your choice, but in this case, you should not complain
that this took you 70 hours of work.

Building GPS with -bargs -static would have taken you less than one hour to
build, and you would still use other shared libs, such as gtkada.

> This is great news.

Thanks. As you can see, things are moving in the right direction.

> BTW, here is another idea that just crossed my mind: how about
> separating the project file routines into their own shared library
> (e.g. libgnat-project.so)? This shared library would be built along
> with libgnat, but used by GPS, gnatmake, and all other project-aware
> tools.  It would also allow third-party developers to make their own
> tools project-aware (this could be interesting for ASIS-based tools,
> for example).  I'm willing to help do this if you think that it's a
> good idea.

This is much trickier than it sounds: first shared libraries are very
complicated beasts, and getting them right on all platforms is *very*
tricky. You only have to worry about linux, so that's not so much of
an issue for you, bit it is for us. Then, having an ASIS-like
interface for projects would be redoing completely the interface which
was not designed as a high level interface like ASIS.

Note that with GPS 2.x (see e.g. the daily snapshots), you can write quite
elaborated scripts in e.g.  python that can query most properties of the
project using GPS shell commands, and act accordingly.

Arno