Hi!
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.
The project-manager is the wrong place to do something that is specific to C/C++ projects IMHO. Any other projects don't need to parse those directories even if they use pkg-config to check if everything is installed correctly. And you also don't need this symbols until the user opens a C or C++ file.
Then, is the symbol db plugin interested by knowing the packages ?
No, we don't care about the packages at all. The method could as well be called add_files(). The symbol-db plugin will have to check anyway, if those files are in the database already. Sorry for being misleading here.
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.
I don't see a reason why we should make the database more complicated by adding this association somewhere. It is far easier to do this on the fly. And again, project-manager shouldn't do C/C++ specific things.
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.
I never planned to update the headers everytime. My plan was to copy the (already scanned) symbols of those headers to a temporary database that is used for searching. This is just a database operation, nothing will be rescanned here. The reason for copying is basically that I think otherwise we need a very complicated SELECT to only get the symbols we want (and we still had to merge those with the project symbols).
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.
Yes, from add/remove the temporary database. So, I will try to make this clear again: * symbol-db will scan all the include dirs we have with pkg-config * language-support will tell symbol-db which header files are necessary for the current file * symbol-db copies the symbols of these files to a temporary database in memory * searches will be performed on this temporary database. Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part