Hi! As a follow-up of yesterday's IRC discussion some ideas how a future symbol-db could work. Global-DB: ---------- General: The symbol-db should automatically scan all symbols from packages we can find using the pkg-config parsing of the project manager (+ meta-package for libc and libstdc++). 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) Get exact symbols for a file : (see https://bugzilla.gnome.org/show_bug.cgi?id=630198) 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. Pseudo SQL SELECT WHERE (file-list contains filename) from symbols >> temporary database While we still might want to do this query in an async fashion this should be reasonable fast (<< 1 sec) for creating the temporary database. Searches would be performed on the temporary database. We could even do the same for the project files database but two problems arise: * gcc only gives us relativ paths for those files (well, we can solve this) * we would need to update the temporary database when the file is saved by keeping the project database consistent. That could be tricky. On the other hand we probably want to regenerate the database anyway when the file is saved because there could be more include files now. As a sidenote, that temporary database could be used for the "File" tab or symbol-db, too. Advanced queries (lower priority) ---------------- I think I posted about this some months ago. Actually we would need something like this (simplied) symbol_query_in_scope (SymbolIter* scope, const gchar* search_string) which would return all found symbols that are available in scope including those of global scope. As an example if the scope is a method inside a class: ->scope of method ->scope of file ->scope of class ->scope of parent class(es) ->scope of namespace ->global scope This would make C++ autocompletion really easy and probably also make the code in language-support-cpp-java much shorter especially when all queries only go to the temporary database. Maybe that's easy SQL, maybe it means reorganizing that database, I don't know. It's not high-priority but would be nice to have. So, does this make sense to you. Am I overseeing something important? Is this difficult to implement? I will do the stuff in language-support (and libanjuta) if necessary but I have still no real idea how symbol-db fits together... Thanks for reading, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part