Re: [anjuta-devel] New project-manager and symbol-db

[Sébastien Granjoux <seb sfo free fr>]

Hi Johannes,,

Le 18/11/2010 15:55, Johannes Schmid a écrit :
> There seems to be a bug in the way the project-manager and symbol-db
> work together. Basically the whole project is rescanned on each
> start-up. Don't know exactly why this happens.

Currently, the symbol-db doesn't use the package found by the project 
manager. It get only the module names and is finding the package itself 
using the old ianjuta_project_manager_get_packages function.

Then, the project is not loaded in one time. It's quite possible that 
symbol-db plugin see a project without any packages and see new package 
afterward. It's possible to fix it but I don't know what is the best 
solution to do it.


> It also seems that something is causing anjuta to be very slow in the
> 10s after a big project was opened. I expect the symbol-db to do some
> (probably unnecessary) work but not sure.

It's quite possible due to the symbol-db plugin rescanning everything. 
The project manager needs some time to get all sources files of all 
packages.

> With the --print-requires switch we are able to sort these paths out to
> only get those files to belonging to the particular packages. But I am
> not sure how we should interact with the project-manager there and how
> the project-manager would work together with symbol-db.

Me neither at the moment.

> I don't know if a tree like this would be acceptable for the
> project-manager:
>
> ->  MODULE
>   ->  GTK
>     ->gtk+-2.0
>       ->gtk-only files
>       ->glib-2.0
>         ->glib files
>       ->atk-2.0
>         ->...
> out of this source: PKG_CONFIG_MODULE (GTK, gtk+-2.0).

It's not working like this currently, but it's acceptable.

> The other issue still open is with packages that return something like
> "/usr/include" as the include path, while their real files are inside
> "/usr/include/<package_name>.

> The idea is to have some (hard-coded) mapping for such packages. That
> isn't really nice but would solve the problem and is easy to implement.
> It is a bit of a pain to maintain of course.

I think it would be better to extract the include files from the source 
itself. So rather in the language-support plugin.

Then, I think it would be better that instead of having the symbol-db 
plugin requesting the header files. Each plugin which knows the header 
files send them to the symbol-db plugin. In C, the language support 
plugin and the project manager. For python, I think they are defined 
with import, so known by the language support plugin only.

I don't know how to send this information though. Perhaps having a 
function in the symbol-db which is called by other plugin. Or having a 
signal emitted when a new header is known. This last solution will allow 
several plugins to know these headers not only the symbol-db plugin.


Best Regards,

Sébastien