Re: [anjuta-devel] RFC: Symbol-db future

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

Hi,

Le 10/12/2010 15:16, Johannes Schmid a écrit :
> As this depends on the language used (and it
> doesn't make sense to create a database if we have only non-C languages
> used) this will be handled by the language-support plugin:
>
> * Get the packages from the project-manager
> * Check for dependant packages and their include dirs (new libanjuta
> API)
> * Call ianjuta_symbol_manager_add_package() for all needed packages
> (we can skip package_(de)activate probably - see below)

I think this could be handled by both the project manager (for package) 
and the language support plugin (for include files).

I think the project manager can call itself 
ianjuta_symbol_manager_add_package without needing the intervention of 
the language support plugin. It could be more difficult for the language 
support plugin to do it because the packages header are loaded with some 
delay.


Then, is the symbol db plugin interested by knowing the packages ?

I think it could be easier to send it directly all the header files 
without splitting them in packages. One thing that is interesting though 
is to tell to the project manager which header files are associated with 
which source files. By example having

ianjuta_symbol_manager_add_file (GFile *source, GFile *header);

We can use a GList of GFile* to avoid some call of this function. The 
project manager has to call this function for all sources files with all 
headers of all packages. The language-support plugin can call it each 
time a new file is displayed with only the included header.


> We can get a list of files included by a particular source file using
> "gcc -MM file.c -I..." and as we know the include directories from
> pkg-config we can also easily add the needed -I flags. This is also a
> responsibility of the language-support plugin.
>
> As it would take too long to rescan those files everytime and we already
> have the global database I was thinking about creating a temporary
> (in-memory) database holding only the symbols we want.

I think it's possible to keep in a database saved on disk which give you 
all symbols for a given header file and all header files used by a given 
source file. So, we don't have to rescan all headers everytime.

If a source files is updated, the language-support plugin will check 
again its include and  call a function of the symbol db plugin to remove 
or add some header files.

I think it doesn't matter that much if the database is a bit slow to be 
updated if it doesn't block the ui.


Regards,

Sébastien